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SECTION  I 
INTRODUCTION 

1.1  PURPOSE  AND  SCOPE  OF  STUD* 

The  overall  SENET-DAX  study  is  directed  towards  investigating 
the  concept  of  an  integrated  voice/data  switching  system  based  on 
dynamic  allocation  of  variable-sized  increments  of  a flexible  time 
division  multiplexing  transmission  system  [3,4,27].  This  permits  a 
unified  transmission  and  multiplexing  structure  that  exhibits  a high 
level  of  transmission  efficiency  not  obtainable  by  separate  voice  and 
data  systems,  while  supporting  widely  disparate  types  of 
communications.  Since  the  primary  cost  of  many  military  communication 
networks,  particularly  intercontinental  and  global  communication 
networks,  is  in  the  transmission  segment,  integrating  a variety  of 
differing  traffic  types,  in  this  manner  can  lead  in  the  future  to 
communication  systems  that  are  economically  practical. 

During  the  Phase  I portion  of  the  study  [26],  the  feasibility 
of  the  SENET-DAX  concept  in  terms  of  structure  and  performance 
characteristics  was  analyzed  and  the  concept  was  translated  into 
representative  hardware  and  software  techniques  that  could  be  used  for 
the  conceptual  design  of  an  access  area  exchange.  One  system 
architecture,  the  distributed  microprocessor/roemory  approach  to  the 
SSNET-DAX  concept,  was  chosen  as  the  recommended  implementation  based 
upon  the  advantages  accruing  from  its  functional  and  physical 
partitioning  and  the  corresponding  independent  operation  of  its 
constituent  processing  elements. 
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The  purpose  of  the  portion  of  the  study  described  in  this 
report  has  been  to  analyze  further  the  integrated  voice/packet/data 
transmission  concept  established  in  the  Phase  I effort,  and  to 
determine  how  it  nay  be  realized  from  generally  available  hardware, 
software,  and  firmware  processing  modules.  Alternate  conceptual 
system  designs  for  an  access  area  exchange  model  were  investigated  and 
an  experimental  approach  to  examine  the  integrated  voice/data 
switching  and  multiplexing  technique  for  access  area  application  was 
formulated.  In  contrast  to  Phase  I,  the  conceptual  designs  developed 
in  this  report  emphasize  processor  architecture  and  software  structure 
for  an  experimental  model  whose  primary  purpose  is  to  demonstrate  the 
workability  of  the  basic  SENET-DAX  transmission  concept  in  a realistic 
environment.  In  addition,  the  designs  were  to  maximize  the  use  of 
hardware,  firmware,  and  software  processing  modules  presently 
available  or  expected  to  be  widely  available  in  the  future  without 
special  design.  The  basis  for  the  architectural  designs  to  be 
considered  were  those  established  in  accordance  with  the  Phase  I study 
effort  and,  as  available  at  the  time  of  contract  initiation,  other 
conceptual  designs  accomplished  through  other  independent  and  related 
CCA  studies. 

1.2  TECHNICAL  APPROACH 

The  following  technical  approach  was  used  during  the  course  of 
the  study.  As  a consequence  of  the  design  experience  aeguired  during 
the  Phase  I study,  it  was  possible  to  define  fundamental  SENET-DAX 
concepts  and  to  identify  features  necessary  in  order  to  demonstrate 
workability  of  the  concept  in  a realistic  environment  {e.g,  in  the 
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presence  of  noise) . Next,  several  alternative  system  designs  were 
developed,  each  of  which  was  capable  of  demonstrating  the  workability 
of  the  basic  concept.  Among  these  were:  the  class  of  systems  using  a 

distributed  processor  architecture,  the  configuration  recommended  in 
Phase  I;  a central  processor  architecture;  and  a multiprocessor/ 
multimemory  interconnect  architecture  as  described  in  [25] . Section 
2 describes  the  various  approaches  to  the  processing  architecture  and 
associated  software  structure  which  were  considered  here  for  the 
access  area  exchange  model.  In  Section  3 the  most  applicable  and 
cost-effective  of  these  designs,  the  distributed  model,  was 
recommended  for  the  access  area  exchange.  The  basis  for  this  choice 
was  derived  from  several  factors.  One  was  a timing  analysis  that  was 
made  for  certain  basic  time-critical  software  routines  in  the  model, 
e.g.,  real-time  clock  interrupt  and  packet  analysis  processing.  These 
software  functions  are  time-critical  in  the  sense  that  most  are 
repetitive  and  require  real-time  or  close  to  real-time  processing 
capability.  Our  conclusion  for  the  recommended  architecture  was 
further  supported  by  data  obtained  from  the  equipment/software  survey, 
evaluation  of  link  memory  access  capability  and  estimates  of  system 
cost.  The  distributed  model  was  specified  first  in  functional  block 
form,  where  each  block  is  associated  with  the  functions  it  performs. 
For  example,  link  hardware  performs  the  functions  of  star t-of-frame 
detection,  bit  stuffing,  redundancy  error  checking,  and  packet  flag 
detection.  In  the  next  step,  a more  detailed  design  was  specified. 

It  was  from  this  level  of  detail  that  we  based  our  estimated  system 
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In  Section  4 we  report  the  results  of  an  eguipment/software 
survey,  which  was  undertaken  to  identify  the  available  processing 
modules  to  be  used  as  building  blocks  in  the  recommended  conceptual 
design.  Vendor  literature  was  solicited  and  several  vendors  were 
brought  in  for  meetings.  Survey  areas  that  related  to  equipment 
included  size,  availability  and  cost,  along  with  diverse  operational 
capabilities  and  alterability  within  an  experimental  environment.  The 
software  investigation  dealt  with  the  evaluation  of  instruction  sets, 
availability  of  program  development  and  systems  support  from  the 
manufacturer,  and  program  development  costs. 

An  approach  which  can  be  used  to  examine  experimentally  the 
integrated  voice/data  switching  and  multiplexing  technique  is 
described  in  Section  5.  Several  alternative  access  area  exchange 
configurations  were  evaluated  toward  an  experimental  network  for 
system  test  and  evaluation.  The  basis  of  choice  was  the  capability  to 
provide  the  features  necessary  to  demonstrate  the  workability  of  the 
SENET-DAX  concept  in  a realistic  environment,  yet  be  cost-effective  as 
well.  ’ The  recommended  network  for  system  testing  is  described  more 
fully  in  paragraph  1.3. 

A performance  evaluation  of  the  merits  of  the  recommended 
conceptual  design,  the  distributed  processing  model,  was  made  as  a 
function  of  switching  capabilities,  and  the  results  were  reported  in 
Section  6.  Among  those  performance  criteria  evaluated  were 
transmission  efficiency  and  throughput  as  a function  of  packet  size, 
bit  error  rate,  and  error  control  protocol;  blocking  and  delay  of 
voice  and  data;  system  traffic  and  sizing  characteristics;  trunk 
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handling  capability;  and  cross  office  and  cross  network  delays. 

Results  are  shown  in  a parametric  fashion  where  possible. 

Cost  estimates  for  the  recommended  conceptual  design  model  and 
the  experimental  net  orks  compored  of  these  models  are  provided  in 
Section  7.  The  implementation  costs  for  the  distributed  architecture 
model  were  derived  from  the  detailed  hardware  diagram  developed  in 
paragraph  3.3.  Costs  are  itemized  on  the  basis  of  hardware  estimates 
only;  engineering  and  software  development  costs  are  not  included 
{except  for  certain  development  aids  as  they  relate  to  the  hardware) . 
Cost  charts  are  provided  and  offer  a relative  comparison  of  network 
costs  as  a function  of  network  complexity. 

Section  8 concludes  the  report  with  a recommendation  for 
further  investigation  into  certain  areas  which  have  great  potential 
application  toward  an  experimental  SENET-DAX  access  area  exchange 
multi-node  network.  These  include  communication  over  satellite  links 
and  interface  with  the  ARPA  network. 


1.3  EXPERIMENTAL/DEMONSTRATION  NETWORK 


The  ultimate  objective  of  this  study  effort  is  to  be  able  to 
design,  build  and  test  experimental  models  in  equipment  and  software 
that  will  demonstrate  the  practicality  of  the  SENET-DAX  transmission 
concept  in  a realistic  network  environment.  To  this  effect, 
integrated  voice/data  switching  centers  are  configured  in  a complex 
network  organization  for  system  test  and  evaluation.  In  the  system 


organization#  only  the  processing  power f memory  capacity  and  terminal 
service  capability  necessary  to  explore  the  concept  for  a working 
model  based  on  the  5ENET-BAX  concept  are  provided. 


The  basic  SENET-DAX  concepts  to  be  demonstrated  include: 


a.  Integration  of  voice  (Class  I)  and  data  (Class  II)  and 
their  interaction  in  a single  switching  system 

b.  Dynamic  allocation  of  channel  capacity  (voice  and  data) 
in  variable  sized  increments  of  the  Class  I and  II 
regions  to  provide  efficient  and  non-interfering 
communication  through  the  switched  trunk  network.  This 
includes  dropping  of  channels  for  new  calls#  and 
recompacting  the  frame  after  detection  of  call  release 

c.  Servicing  of  voice  subscribers  utilizing  different  voice 
rates  (various  channel  widths)  and  a variety  of  current 
inventory  and  development  eguipment 

d.  Servicing  of  data  terminals  with  different  control 
philosophies#  e.g.#  interactive  graphic  and 
guery/response  terminals  using  packet  switching 
techniques,  and  narrative  and  bulk  data  terminals  using 
store  and  forward  techniques 

e.  Movable  boundary  between  classes  of  data  where 
packet-switched  data  traffic  is  allowed  to  occupy 
transmission  capacity  not  used  by  circuit-switched  voice 
traffic,  and  vice  versa. 

Table  1-1  identifies  the  services  necessary  to  demonstrate  these 
fundamental  concepts  in  a realistic  environment. 


A number  of  network  configurations  were  considered  for  the 
experimental  model  that  could  demonstrate  the  fundamental  SENET-DAX 
concepts  and  provide  the  services  listed  in  Table  1-1.  Figure  i-1 
illustrates  an  experimental  four-node  network  with  the  connecting 
links  operating  full-duplex  at  a rate  of  230.4  kBPS.  Each  node 
consists  of  a SENET-DAX  switch  with  tandem  capability  and  a limited 
number  of  directly  connected  digital  subscribers. 
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TABLE  1-1. 


SENET-DAX  SERVICES  TO  DEMONSTRATE 
WORKABILITY  OF  THE  BASIC  CONCEPT 


Multiple  voice  rates 


Dynamic  allocation  of  Class  I 
region  including  drop,  insert, 
and  recompacting  data 


Integrated  voice/data  with 
movable  boundary 


Call  setup  with  forward  reser- 
vation and  backward  allocation 


Call  release 

Common  channel  signaling 
CCIS  artificial  precedence 


Precedence  and  preemption  of 
voice  and  data 


Multiprecedence  in  a 
packet  network 


Preemption-Class  I. data  by 
Class  I 


Delay-Class  II  data  by 
Class  II 


ADCCP  procedures  for  data  & CCIS 


Packet izing/depacketizing 
data  and  CCIS  messages 


. Data/CCIS  error  control 
Protocol  processing 


Link  protocol 
CCIS  protocol 
Originating/terminating 
DAX  protocol 


Dynamic  alternate  routing 

Voice  and  data  terminal  interfaces 

Network  synchronization 


Frame  synchronization/ 
^synchronization 


Linked  list  processing 
Satellite  delay  modelling 
Data  terminal  throttling 


. Precedence  reconciliation 
between  data  classes 


Voice  service  includes  10  to  12  subscribers , primarily  16  kBPS 
and  32  kBPS  CVSD  terminals,  with  possibilities  for  2400  BPS  vocoders, 
and  50  kBPS  KY-3  voice  terminals.  Only  compatible  (technique  and/or 
transmission  rate)  voice  terminals  will  be  allowed  to  converse;  no 
voice  rate  conversion  between  non-compatible  terminals  will  be 
incorporated.  Data  terminals  will  include  teletypes  at  different  baud 
rates  (110,  150,  and  300  baud) , facsimile  terminals,  and  possibly 
computer  terminals. 

Hie  trunk  rate  of  230.4  kBPS  is  a commercial  common  carrier 
standard  and  is  available  for  rental  from  the  telephone  company.  This 
choice  of  a standard  transmission  rate  seemed  a practical  solution  to 
the  problem  of  using  a lower  carrier  rate  tha*>  was  used  in  Phase  1, 
but  having  the  capability  of  handling  sufficient  traffic  to 
demonstrate  the  SEKET-DftX  concept.  Figure  1-1  shews  a maximum  of 
three  230.4  kBPS  trunks  at  a given  node.  However,  to  allow  for 
expandability,  each  node  in  the  network  was  designed  for  a maximum 
capability  of  handling  five  trunks. 

This  network  will  support  the  d«*eR*.irrati«n  of  all  the  basic 
services  listed  in  Table  1-1,  including  recovery  irom  blocking  and 
full  alternate  routing  capability.  The  model  v?ill  accommodate 
satellite  radio  links  between  switching  nodes.  For  laboratory 
purposes  satellite  delays  nay  be  simulated  by  delay  lines. 

In  order  to  allow  network  links  to  be  occupied  by  a wide 
distribution  of  data  for  experimental  purposes,  a table  driven  traffic 
generator  will  be  designed  as  part  of  ths  access  memory.  Each  switch 
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will  thus  have  the  capability  to  generate  traffic  to  occupy  trunks 
without  requiring  the  use  of  terminals.  This  feature  provides  added 
flexibility  in  generating  voice  calls  ai.n  4ata  messages  of  varying  bit 
rates  without  having  to  provide  mo?"'  i terminals  and  hence 
.increase  system  complexity.  Class  1 ca  is  established  via  the  traffic 
generator  would  use  CCIS  procedure  to  j* ■ t.  up  and  break  down  the  calls 
between  switches,  but  would  not  employ  ?-,,  yscr ifcer  signaling  (ringback, 
ring  forward,  dial  tone,  etc.),  since  subscribers  would  not  exist  for 
these  calls. 
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2.1  GENERAL 


SECTION  2 

SYSTEM  DESIGN  ALTERNATIVES 
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Syrtems  utilizing  fiu'.tiple  processors  are  tc&"iy  beginning  to 
see  increased  application  in  a number  of  environments  that  only  a few 
short  years  ago  would  have  been  implemented  by  large  monolithic 
systems.  The  traditional  problems  of  multiprocessor  systems  have  been 
well  documented  and  include  considerations  of  cost,  computational 
capability,  large  complex  system  software,  memory  access  conflicts  and 
methodologies  for  parallel  task  execution. 
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In  carrying  forward  the  exploration  of  the  Phase  I results 
toward  the  suitability  for  modeling,  and  in  view  of  the  *&ove 
complexities  of  multiprocessor  architecture,  this  study  focuses  ^ariy 
on  an  objective  review  of  alternative  designs  so  that  maximum 
advantage  could  be  taken  of  reduced  model  requirements.  Three 
candidate  system  designs  were  developed  and  examined  with  respect  to 
their  capability  to  demonstrate  the  workability  of  the  basic  concept 
and  for  factors  relating  to  their  reliability  and  software  complexity.. 
Each  design  necessitated  sufficient  investigation  to  determine  its 
suitability  or  dismissal  when  weighed  against  established  design  g^als 
and  desired  capabilities  of  the  model.  Other  multiprocessor 
configurations  referenced  in  the  bibliography,  were  reviewed  for 
applicable  technology  and  methodology  adaptable  to  this  application. 
[7,18,22]. 


2-1 


2.2  CONCEPTUAL  DESIGN  MODELS  CONSIDERED  IN  THE  STUDY 

The  sye tea  designs  considered  in  this  study  include: 

a.  A multlprocessor/Kultimemory  interconnect  structure 
based  upon  the  Carneg  ie-Mel Ion  Cmtp  report 

b.  A central  processor  approach 

c.  The  distributed  micro-computer  approach  as  recommended 
in  Phase  I. 

The  models  are  specified  in  functional  block  fora  in  the  following 
sections. 

2.3  MBLTIPRQCESSOR/NULf  MEMORY  INTERCONNECT  STRUCTURE 

Figure  2-1  displays  an  architecture  based  upon  the 
multiprocessor  configuration  presented  in  the  Carnegie-Hellcn  report. 
With  reference  to  this  figure*  certain  advantages  may  be  identified. 
These  advantages  include  the  ability  to  gracefully  degrade  performance 
as  the  result  of  the  failure  of  a task  processor.  Under  this 
condition*  all  trunks  can  continue  to  be  serviced  at  a reduced  rate. 

It  should  also  be  noted  that  this  system  exhibits  nodular  growth  in 
terms  of  trunk  and  access  servicing. 

Hoover  the  architecture  cannot  be  considered  a viable 
candidate  system  fro*  the  point  of  view  of  required  reliability. 

There  «re  a number  of  single  thread  elements  whose  redundancy  would 
have  an  impact  on  system  cost  and  complexity. 
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Multiprocessor/Multimemory  Interconnect  Structure 


The  master  control  processor  responsible  for  task 
decomposition  and  task  assignment  to  other  processors  is  itself  a 
single  thread  element  along  with  the  primary  memory 
switching/addressing  element  £Smp)  and  control  bus.  Methodologies  for 
task  allocation  for  pipeline  processing  are  not  well  established  and 
the  number  of  processors  would  require  a complex  system  software 
control  structure  that  would  have  a negative  effect  on  system 
performance.  Since  the  number  of  tasks  is  independent  of  the  site 
size,  this  configuration  exhibits  high  cost  for  smaller  sites  an<‘- 
anticipated  poor  performance  at  larger  sites  due  to  increased  memory 
access  conflicts.  These  overriding  disadvantages  precluded  further 
detailed  consideration  of  this  architecture  in  view  of  more  promising 
alternative  configurations. 

2.4  CENTRAL  PROCESSOR  APPROACH 

The  impetus  for  consideration  of  this  approach  stemmed  from 
the  desire  to  take  advantage  of  any  relaxation  of  system  requirements 
achieved  in  defining  the  design  goals  and  capability  of  the 
experimental  model.  Two  areas  where  such  relaxation  is  achieved  are 
in  the  proposed  transmission  speed  and  in  the  number  of  representative 
subscribers  necessary  to  validate  the  design  experimentally.  In  the 
latter  case,  provision  for  the  following  set  of  typical  terminal  rates 
insures  adequate  representation  consistent  with  reasonable  system  test 
flexibility  and  interface  costs. 
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Typical  Terminal  Rates 


110  8aud  1 
2.4  kBPS  I 

S.6  kBPS  l Assumed  loading  of  up  to 

16.0  kBPS  | 12  subscribers  per  node. 

32.0  kBPS  V 

50.0  kBPS  I 

Common  carrier  equipment  sufficient  to  handle  the  above 
aggregate  subscriber  rate  is  commercially  available  at  a line  rate  of 
230.4  kBPS  and  is  therefore  proposed  as  the  transmission  speed  for  our 
model.  This  represents  the  second  area  where  relaxed  performance 
requirements  suggest  that  a centralized  approach  nay  be  utilized  in 
order  to  demonstrate  the  concepts  of  the  SEHBT-DAX  system. 

Further  examination  of  the  interrupt  service  rate  required  by 
a bi-directional  50  kBPS  subscriber  reveals  that  an  80  ysec  processing 
interval  is  all  that  is  available  to  set vice/process  incoming  and 
outgoing  data  bytes.  A single  processor  cannot  provide  software 
servicing  at  these  rates  even  if  that  were  all  it  was  required  to 
perform*  For  this  reason,  the  configuration  shown  in  Figure  2-2  is 
separated  into  two  processors  in  order  to  off-load  real-time 
subscriber  access  onto  the  digital  access  controller.  In  this 
arrangement,  network  processing  such  as  list  management,  routing  and 
packet  analysis/generation  must  be  performed  by  the  trunk  processor 
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There  are  two  outstanding  considerations  inherent  in  this 


approach.  First,  the  trunk  processor  must  be  capable  of  concurrently 
processing  the  input  and  output  network  functions,  and  second,  the 
data  memory  must  be  operated  as  a shared  resource  to  avoid  the 
internal  transfer  of  memory  data.  Sharing  this  resource  imposes  the 
necessity  of  a high  speed  control  information  transfer  between 
processors  to  coordinate  the  placement  and  extraction  of  data  which 
adds  to  the  processing  time  constraints  of  both  processors. 
Reliability,  redundancy  and  switchover  considerations  for  single 
thread  elements  create  additional  system  cost  and  complexity  as  they 
did  in  the  maitiprocessor/multiraemory  interconnect  structure  discussed 
in  paragraph  2.3. 

It  is  interesting  to  note  that  relief  for  the  concurrent 
inpufc/output  processing  requirement  of  the  Trunk  Processor,  shown  in 
Figure  2-2,  may  be  obtained  by  further  subdivision  of  this  processor 
into  multiple  processors.  This  strongly -suggests  that  this  case  is  a 
simplex  form  of  the  distributed  architecture  when  the  I/O  speeds  are 
such  as  to  allow  the  contraction  of  all  processing  into  a singular 
element. 

Multiple  processing  elements  again  raise  the  question  of 
sharing  a common  memory  resource  and  whether  a multiprogramming 
approach  to  enhance  CPU  utilization,  degraded  by  memory  access  . 
conflicts,  is  justified. 


TRUNK  PROCESSOR 


Figure  2—2.  Divided  Central  Processor  Configuration 
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2.5  SHARED  MEMORY  CONSIDERATIONS 

r 

A review  of  computer  memory  systems  will  show  that  the 
requirement  for  a shared  memory  resource  grew  out  of  a desire  to 
increase  CPU  utilization  by  allowing  peripheral  I/C  direct  access  to 
the  memory  without  processor  involvement.  Earlier  computer  systems 
labored  under  limited  memory  technologies  which  mainly  divided  between 
electronically  addressable  (core,  semi-conductor)  and 
electromechanical  (tapes,  drums)  devices  which  created  a disparity  in 
accessing  time  in  any  given  memory  hierarchy. 

Under  this  environment,  multiprogramming  concepts  evolved  in 
order  to  continue  task  processing  during  resource  access  intervals, 
assuming  that  the  access  time  was  sufficiently  lengthy  to  justify  the 
overhead  involved  in  task  switching.  The  common  conclusion  of  these 
observations  is  that  multiprogramming  and  shared  memory  techniques 
appear  justified  only  when  the  system  must  deal  with  "access  gaps"  due 
to  different  memory  technologies  and  I/O  equipment  (characteristics 
not  present  on  our  experimental  model). 

Today,  memory  technology  is  making  rapid  progress  in  reducing 
the  differences  between  hierarchal  information  access  times  with  such 
advances  as  charge-coupled  devices  (CCD's),  bubble  memories  with  a 
potential  of  10  million  bits  per  square  inch,  electron  beam  addressed 
memories  (EBAM)  and  domain  type  propagation  (DOT),  [1,15,19,20].  The 
proposed  architecture  for  the  SENET-DAX  model  places  this  system  in  a 
position  to  readily  adopt  these  new  technologies  as  they  become 
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available  for  application  in  the  next  decade,  since  multiprogramming 
complexities  have  not  been  introduced  into  the  conceptual  SEHET-DAX 
design  thereby  enabling  future  system  enhancement  with  minimum 
complication. 


Currently,  100  nanosec  access  time  memories  represent 
state-of-the-art.  Memory  access  requirements  must  therefore  receive 
careful  consideration  in  the  selection  of  a memory  hierarchy,  since  in 
the  application  being  considered  all  devices  peripheral  to  memory  have 
equal  priority  and  service  time  requirements.  Under  these  conditions, 
a shared  memory  approach  reduces  to  a FIFO  (first-in,  first-out) 
service  algorithm  with  contention  resulting  in  system  delays.  The 
inpact  on  memory  access  requirements  with  rero  conflicts  for  a 
distributed  architecture  may  be  compared  with  those  of  a shared  memory 
approach  and  this  comparison  is  shown  in  Figure  2-3. 

With  reference  to  this  figure,  it  should  be  noted  that  the 
calculations  were  done  for  the  experimental  model  transmission  speed 
stated  earlier  (230.4  kBPS)  and  assume  that  the  memory  accesses  are 
not  only  a function  of  the  number  of  processors  (and  therefore  the 
number  of  links)  but  are  also  a function  of  the  number  of  accesses 
required  for  processing  the  stored  data.  The  number  of  processing 
accesses  (Ap)  is  related  to  the  degree  of  software  processing 
complexity,  with  Ap=0  parametrically  establishing  the  lower  bound  when 
no  useful  work  (processing)  is  performed  other  than  storage  and 
retrieval.  It  can  be  seen  that  for  a model  structure  consisting  of  3 
links  the  operating  range  of  the  memory  will  be  between  360  nanosecs 
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with  Ap*15  for  the  shared  system  and  2.9  ysecs  for  Ap*0  for  the 
distributed  approach.  Both  of  these  extremes  lie  well  within  current 
technology  for  implementation  of  a scaled  prototype  system. 


However,  in  order  to  derive  meaningful  experimental  data,  our 
model  architecture  must  closely  approximate  that  of  the  final  system 
wherein  the  maximum  number  of  links  may  reach  15  with  all  links 
operating  at  T1  carrier  rates  (1.544  Mbps).  Due  to  the  different 
transmission  speed  (T1  carrier)  these  points  could  not  easily  be  shown 
on  the  same  plot.  Calculation  of  the  memory  access  requirements  for 
this  case  was  performed  separately  and  show  that  for  a 15-link  system 
the  access  time  requirements,  for  the  distributed  approach,  fall  in 
the  range  of  133  nanosecs  to  216  nanosecs,  depending  upon  the 
complexity  of  processing.  Parameter  Ap  was  allowed  to  vary  in  this 
case  from  zero  (no  processing)  to  a maximum  of  15  (accesses  per  byte 
per  processor) . 

The  results  of  a similar  calculation  for  the  shared  memory 
reveals  that  even  for  an  Ap=0,  the  memory  access  requirement  would  be 
36  nanosecs  while  an  Ap*15  produces  a requirement  of  13.5  nanosecs, 
indicating  that  this  approach  would  clearly  exceed  current 
state-of-the-art  memory  technology.' 


It  can  therefore  be  concluded  that  in  a system  with  equal 
priority  and  service  time  requirements,  neither  shared  memory  systems 
nor  systems  involving  a high  level  ft  multiprogramming  provide  the 
degree  of  performance  exhibited  by  distributed  memory  systems.  In  a 
system  of  equal  priorities  and  an  era  of  rapidly  advancing  memory 
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technology  in  which  there  is  no  question  that  the  future  for  memories 
is  one  of  higher  densities,  faster  speeds  and  lower  cost  per  bit,  we 
are  firmly  convinced  that  distributed  memory  systems  will  permit 
higher  performance  with  complex  processing  for  a given 
state-of-the-art  and  more  easily  permit  the  adaptation  of  new  memory 
systems  as  these  become  available. 


2.6  DISTRIBUTED  SYSTEM  ARCHITECTURE 


A system  concept  incorporating  distributed  processors  coupled 
with  distributed  data  memories  is  characteristically  one  in  which  data 
throughput,  application  versatility  and  system  reliability  are 
optimized  through  the  modular  partitioning  of  system  functions. 

Whereas  a multiple  processor/memory  interconnect  system  through 
parallel  processing  increases  the  data  throughput  rate  while  providing 
graceful  single  failure  degradation  characteristics  and  distributed 
diagnostic  capabilities,  system  overhead  can  be.  large  due  to  the 
supervision  required  for  high  speed  interprocesser  communications. 

This  overhead  can  be  of  sufficient  complexity  as  to  compromise  such  of 
the  throughput  advantage. 

In  an  attempt  to  maximize  all  desirable  characteristics  ol  a 
distributed  system,  the  distributed  architecture  illustrated  in  Figure 
2-4  has  been  developed.  This  system  is  characterized  by  a dual  bus 
structure  with  a continuous  cycle  bus  scheduling  clock.  The  total 
interprocessor  communications  overhead  function  is  performed  simply  by 
a clock  driven  multiplexer  which  multiplexes  all  data  and  control  bus 
transfers.  For  processor-to-data  memory  access  across  the  bus,  delay 
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is  minimized  by  assuring  port-to-data  bus  access  ae  least  once  per 
byte  time  based  on  the  highest  rate  I/O  transfer.  Real-time  bus 
scheduling  for  port  hardware  eliminates  priority  rating  and  interrupt 
contention  delays.  At  each  bus  port#  a first-in-fi* st-out  buffer 
collects  chronological  control  bus  transfers#  which  were  addressed  to 
that  port,  for  time  ordered  precedence  processing  of  required 
operations. 


The  bus  port  hardware  indicated  in  Figure  2-4#  which  is 
incrementally  expandable  on  the  buses#  contains  one  or  more 
processors#  a portion  of  system  data  memory  and  customized  I/O 
hardware  (Figure  2-5).  The  modular  independence  of  both  the  port 
processor  and  the  associated  data  memory  provides  high  system 
reliability.  System  reliability  is  further  enhanced  by  protecting  all 
port  data  memories  from  erroneous  modification.  This  is  accomplished 
by  allowing  only  a port  input  processor  to  alter  the  contents  of  its 
associated  data  memory. 

Generally,  this  distributed  system  architecture  also  provides 
a high  degree  of  application  versatility.  In  view  of  the  modular 
programmed  control  per  port#  a wide  variety  of  I/O  circuit  or  lines 
may  be  serviced  simultaneously  by  one  system.  Depending  on  the  type 
of  I/O  servicing  required  at  a bus  port#  the  programmed  element 
utilizes  a communications  interface  module  for  direct  I/O  control  or 
to  perform  a more  supervisory  function  over  remote  operation. 
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The  distributed  system  architecture  presented  herein  provides 
a system  method  for  satisfying  the  extensive  requirements  of  high  data 
throughput  speed,  operational  and  application  versatility,  and 
reliability.  These  desirable  system  characteristics  are  facilitated 
by  the  modular  partitioning  of  system  functions,  coordinated  via  a 
uniquely  controlled  bus  structure. 

2.7  OTHER  DESIGN  CONFIGURATIONS 


Although  tine  did  not  permit  an  in-depth  study  of  all  systems 
in  the  periphery  of  multiprocessor  configurations,  two  additional 
systems  were  reviewed  for  their  architectural  applicability  to  the 
SENET-DAX  concept.  IT, 181. 

The  associative  processing  technique  put  forth  by  Honeywell 
Systems/Research  Center  provided  for  the  compression  and  multiplexing 
of  digitized  voice  and  data  by  individually  assigned  line  processors. 
From  an  architectural  standpoint,  a common  bus  structure  was  employed 
between  the  master  control  processor  and  all  line  processors  and  as 
such  is  not  directly  applicable  fot  the  reasons  stated  earlier  in  this 
section  on  centralized  processing. 


The  Pluribus  configuration  as  described  by  Bolt,  Becanak  and 
Newman  utilizes  a pool  of  processors  that  sre  distributed  along  with 
their  assigned  memory  elements,  to  a multiplicity  of  buses.  Each 
basic  building  block  is  therefore  composed  of  two  processing  elements, 
two  memories  and  a bus  with  a standardized  interface.  Systems  are 
configured  by  full  interconnectivity  of  the  individual  buses  with  all 
processors  equally  available  for  task  processing  as  tasks  become 
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available  in  a central  hardware-controlled  task  queue.  The  modularity 
of  this  system  would  appear  to  make  it  extremely  suitable  for  a wide 
variety  of  applications  with  apparent  high  reliability.  It  is  our 
cur-rent  observation  that  the  present  structure  is  based  on  a 
distribution  of  tasks  akin  to  a multiprogramming  structure  which  we  do 
not  believe  to  be  well  suited  for  the  SENET-DAX  system.  It  is  also 
noted  that  memory  access  conflicts  are  resolved  by  having  each  bus 
contain  its  own  conflict-resolution  hardware.  While  a formidable 
amount  of  raw  processing  power  appears  to  have  been  provided  in  a 
modular  structure,  inter-processor  communication/handshaking  appears 
to  introduce  internal  delays  along  with  the  possibility  for  "glare" 
situations  to  develop.  However,  the  complex  combinatorial  processing 
of  such  a system  would  require  considerable  further  study  prior  to 
forming  a definitive  evaluation. 
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5. 

SECTION  3 

RECOMMENCED  DESIGN  CONFIGURATION 

3.1  GENERAL 

The  system  design  configuration  recoeiRended  for  sodeling  a 
SENET-DAX  network  must  economically  and  operationally  satisfy  many 
diverse  network  and  nodal  criteria  while  demonstrating  the  SEKET-OAX 
concept.  These  criteria  include  worse  case  operational  demands,  the 
need  for  minimal  system  overhead  in  limited  service  environments* 
modular  expandability,  high  system  reliability,  automatic 
self-diagnostics,  and  the  ability  to  statistically  analyze  and 
quantify  operational  procedures  and  events. 

In  the  experimental  laboratory  environment,  each  network  node 
will  probably  be  required  to  service  up  to  three  high  speed 
full-duplex  trunk  links,  each  at  230.4  Kb/s  or  less,  with  an  upper 
limit  of  five  links.  At  the  access  level,  twelve  terminations  would 
be  an  assumed  upper  bound.  Most  of  these  access  terminations  would  be 
synchronous,  with  rates  up  to  50  Kb/s.  The  remaining  would,  be 
asynchronous  with  assumed  maximum  operating  speeds  of  9.6  Kb/s. 

The  worse-case  operational  demands  based  on  the  input/output 
rates  above  disqualify  a central  processor  approach,  (as  will  be 
discussed  in  paragraph  3.3).  The  processing  time  required  to  simply 
service  the  operational  I/O  would  leave  no  time  for  diagnostics  or 
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statistics.  In  addition*  the  central  processor  approach  for  the 
application  provides  reduced  system  reliability,  contains  a maximum  of 
system  overhead,  and  does  not  allow  for  total  wodular  expandability. 

The  Carnegie-Mellon  multiprocessor  syste*  approach  satisfies 
more  system  criteria  than  the  central  processor  approach.  This 
multiprocessor/shared-data-memory  system,  while  allowing  a greater 
degree  of  modular  expandability,  higher  reliability  due  to  the 
multiple  processors,  and  distributed  diagnostic  and  statistical 
capability,  requires  a considerable  system  overhead  function.  This 
overhead,  which  is  necessary  for  the  task  scheduling  of  the  system 
processors,  significantly  compromises  system  data  throughput  and 
limits  real-time  reaction  speeds.  System  reliability  and  data 
throughput  both  suffer  somewhat  when  a central  shared  memory  is  used. 

Since  the  distributed  system  architecture  utilizes  a 
multiprocessor  structure  with  distributed  data  memory  and  very  low 
system  overhead,  this  architecture  is  an  interesting  option*  Hhen  it 
is  also  recognized  that  this  architecture  provides  total  modular 
expandability,  high  system  reliability  and  a minimal  system  overhead 
which  provides  rapid  no-contention  interprocessor  communication  and 
data  bus  transfers,  the  distributed  system  architecture  stands  as  the 
most  promising  alternative.  Distributed  diagnostics  and  statistical 
compilations  are  also  realizable  features  in  this  system.  Therefore, 
the  distributed  system  architecture  is  recommended  for  the  5EHET-DAX 
model. 
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3.2  FUNCTIONAL  DESCRIPTION  OF  THE  DISTRIBUTED  MOSEL  ARCHITECTURE 

A functional  block  diagram  of  the  SENET-DAX  model  distributed 
system  architecture  is  presented  in  Figure  3-1.  A two  level  fully 
bi-directional  bus  is  the  center  of  all  nodal  activity.  Three 
hardware/software  groups,  which  attach  to  this  bus  structure,  are  the 
nodal  equipment  group,  the  trunk  link  group,  and  the  local  access 
group. 

The  nodal  group  contains  the  system  clocks,  routing  table,  and 
nodal  processor.  All  bus  activity  and  system  I/O  are  coordinated  and 
synchronized  by  the  system  clocks.  The  nodal  processor  performs 
minimal  supervisory  control  over  nodal  activities  by,  for  example, 
updating  the  routing  table  and  interfacing  with  a system  attendant. 

The  bus,  which  has  a total  loading  capacity  of  six  bus  ports, 
can  service  one  local  access  group  and  a maximum  of  five  trunk  link 
hardware/software  groups.  A trunk  link  group  services  one  full-duplex 
trunk  link  at  a maximum  rate  of  230.4  Kb/s*  All  link  protocol 
including  synchronization  is  performed  by  the  link  processors.  The 
link  data  memory,  a portion  of  total  nodal  data  memory,  is  supervised 
by-  the  link  input  processor. 

One  bus  port  is  used  by  a local  access  group.  A maximum  of 
eleven  Class  I and  at  least  one  Class  II  subscribers  interface  to  the 
nodal  bus  structure  via  their  respective  processors.  A customized  DMA 
controller  is  supervised  by  both  processors  to  facilitate  the 
retrieval  of  data  across  the  bus  to  be  transmitted  to  local 
subscribers. 
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Figure  3-1.  SENET-DAX  Functional  Block  Diagram 


3.2.1  Equipment  Processing  Elements 


The  recommended  SENET-DAX  model  functional  architecture  is 
shown  in  Figure  3-2.  The  nodal  processing  element  performs  a remote 
supervisory  function  over  all  system  activities  by  directing 
interprocessor  communications  via  the  routing  table.  The  table 
contents  are  periodically  updated  by  the  nodal  processor  based  on 
diagnostic  and  statistical  reports  received  from  all  other  system 
processing  elements.  All  other  system  processing  elements  perform  the 
primary  task  of  interfacing  a data  input  and/or  output  circuit  to  the 
central  bus  structure.  A nodal  clock  multiplexer  organizes  all  bus 
activities. 

All  processors  have  an  attached  program  memory.  One  clock 
multiplexing  phase  is  assigned  to  each  processor  during  which  it  has 
complete  command  of  the  control  bus.  Each  processor  is  also  assigned 
one  or  more  control  bus  addresses.  For  transfer  of  control  data  over 
the  bus,  the  processor  transmits  a destination  address  with  data  onto 
the  control  bus.  When  an  address  is  recognized  by  the  appropriate 
first-in-first-out  (FIFO)  processor  buffer  (see  Figure  3-2) , specific 
control  bus  information  is  strobed  into  that  buffer.  Control  FIFO's 
receive  ell  control  bus  transfers  related  to  nodal  administration. 
Packet  FIFO's  receive  transfers  concerning  the  traffic  at  that  port. 
These  buffers  facilitate  the  chronological  task  ordering  of  the 
interprocessor  communications  addressed  to  a processing  element. 
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The  nodal  processor  interfaces  an  operator  console  to  the 
control  bus.  Through  this  console  the  operator  may  exercise  complete 
administrative  control  of  any  system  program  memory  or  collect  traffic 
statistics  on  any  system  operation.  If  desired  for  network 
demonstration,  the  nodal  processor  may  be  connected  at  a Class  II 
access-level  data  terminal  connection  to  operate  as  a remote 
query-response  computational  facility. 

At  a link  bus  port,  two  processing  elements  are  required  to 
effectively  service  a trunk  link.  The  link  -input  processor  manages 
the  link  data  memory*  After  supervising  an  input  hardware  DMA  byte 
transfer  into  link  memory,  the  input  processor  analyzes  the  stored 
contents  of  Class  II  packets.  Following  an  analysis,  the  input 
processor  forms  an  acknowledge  packet  in  its  link  data  memory  for 
transmission  by  its  associated  output  processor. 

The  link  output  processor,  after  receiving  traffic  control 
information  through  its  packet  FIFO,  incorporates  the  prepared  packet 
into  the  transmitted  serial  data  stream  by  instructing  the  output 
hardware  to  perform  a DMA  operation  over. the  data  bus  for  the  duration 
of  that  packet.  The  packet  is  preceeded  by  a special  flag  and  a 
sequence  number,  then  appended  by  an  error-checking  cyclic  redundancy 
code  (CRCC)  and  another  flag.  All  link  synchronizing  procedures 
including  flags,  CRCC  and  bit  stuffing  are  performed  by  hardware 
associated  with  the  link  input/output  hardware. 
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The  access  bus  port  also  requires  two  processing  elements.  A 
Class  II  processor  supervises  all  asynchronous  subscribers  and  manages 
the  Class  II  access  memory.  This  includes  the  supervising  of  DMA  byte 
transfers  via  the  data  bus  into  the  Class  II  access  memory  from  link 
memories.  In  addition,  the  Class  II  processor  interfaces  with  a 
console  that  may  be  used  to  place  extra  Class  X/II  traffic  on  trunk 
links  to  facilitate  busy  hour  traffic  studies. 

The  Class  I processor  controls  all  synchronous  subscriber 
servicing.  A special  interrupt  driver  bus  connects  all  Class  I 
subscriber  serial  line  interfaces  together  and  to  the  separate  double 
buffered  Class  I data  memory.  Special  hardware  performs  subscriber 
byte  transfers  and  signal ing/supervis ion  under  the  control  of  the 
Class  I processor.  This  processor  also  controls  a Class  I data  DMA 
operation  from  link  memories  into  Class  I access  memory. 


3.2.2  Software  Requirements 


The  functional  software  elements  required  by  the  system 
architecture  shown  in  Figure  3-1  are  not  unlike  those  software 
functions,  proposed  in  the  Phase  I report b for  processing  of  link 
traffic.  While  the  functions  to  be  executed  remain  the  same,  perhaps 
the  most  important  functional  difference  is  that  the  real-time 
hardware  trunk  interface  is  controlled  by  the  input  and  output 
processors  in  a slightly  different  manner  to  take  advantage  of  the 


lower  transmission  speed  and  simplify  the  control  interface. 
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Class  I buffer  addresses  will  be  provided,  along  with  the 
Class  I field  byte  count  as  in  Phase  I but  the  Class  II  linked  list 
block  addresses  will  only  be  provided  one  at  a time,  as  they  are 
needed  by  input  hardware.  This  will  allow  simple  validation  of  usage 
by  the  link  processors  while  eliminating  additional  address  transfers 
over  the  control  interface. 


The  software  partitioning  allocates  the  system  functions  over 
three  major  areas,  i.e.,  (1)  the  link  port  processors,  (2)  the  access 
port  processors,  which  in  this  case  are  comprised  of  two  separate 
elements  due  to  real-time  access  constraints,  and  (3)  the  nodal 
processor. 


3. 2. 2.1  Link  Processor  Functions 


Input  Processor 


Initialization  and  initial  Class  II  link  list  allocation 
(Data) 

CCIS  analysis  and  generation 
Routing 

Control  switching 

List  management  (input  map,  ack,  sequence  number,  free 
list) 

Test/diagnostic 


Statistics. 


Output  Processor 

a.  Initialization  and  Class  II  link  list  allocation 
(Program) 

b.  Class  I list  processing  (Program) 

c.  Class  II  list  and  queue  processing  (Program) 

d.  Test/diagnostic 

e.  Statistics. 

The  above  processors  operate  in  a background/foreground  mode. 
Interrupt  service  routines  will  service  real-time  line  control 
interface  requests  in  addition  to  internal  messages  via  packet  and 
control  FIFO  bus  interfaces.  The  communications  protocol  employed  by 
these  processors  has  been  chosen  to  be  that  of  ADCCP  operating  in  a 
continuous  ARQ-Type  II  mGde  [24J.  In  addition  to  the  transmission 
efficiency  evaluations  presented  in  Section  6 of  this  report,,  the 
selection  of  Type  II  mode  (retransmission  of  erroneous  packets  only) 
reduces  the  processing  and  queue  size  requirements.  This  is  due  to 
the  decreased  occupancy  time  spent  in  the  transmit  queues  by  validly 
received  pa  *'.ets.  These  packets  would  require  retransmission  in  other 
error  protocols  and  therefore  increase  occupancy  time.  This  would 
reflect  in  an  increased  queue  size  requirement  on  a per  link  basis  as 
well  as  necessitate  the  need  to  prevent  the  reprocessing  of  validly 
received  packets  upon  receipt  of  the  retransmission.  Time  out  of 
acknowledgments  is  also  preferred  as  the  method  of  notification  over  a 
NACK  protocol  since  an  erroneous  HACK  could  result  in  a loss  of 
control  information  (CCIS  packets)  and  Hacking  of  HACKS  becomes  a 
serious  problem  since  the  erroneous  NACK  is  essentially 
indistinguishable  from  any  other  data  error. 
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3. 2. 2. 2 Nodal  Processor  Functions 


The  nodal  processor  is  functionally  similar  to  that  proposed 
in  the  Phase  I study.  The  functions  assigned  to  this  element  include: 

a.  I/O  console  function  (TT3Q 

b.  Initialisation 

c.  Link  and  node  administration 

d.  Routing/traffic  updates 

e»  Test/diagonostic  - link  status 

f.  Node  statistics/measurements 

g.  Debugging  aids. 

The  most  significant  functional  change  for  this  processor  from 
the  Phase  I study  is  the  addition  of  experimental  measurements  and  the 
conceptual  dedication  of  the  hardcopy  I/O  device  for  this  purpose. 

For  the  model,  this  necessitates  the  inclusion  of  a second  I/O  device 
on  the  access  processor  to  allow  the  nodal  processor  console  interface 
to  realize  near  full-time  availability  for  experimental  report 
generation,  monitoring  functions  and  parameter  generation.  The 
environment  of  the  nodal  processor  is  well  suited  to  permitting  this 
additional  processing  burden  due  to  its  relative  insulation  from  the 
real-time  link  and  access  processes  and  the  "quasi-background"  mode  in 
which  most  of  its  processing  is  performed.  Additionally,  as  the  need 
for  new  system  measurements  is  periodically  recognized,  the  statistics 
program  will  no  doubt  be  enhanced  and  will  therefore  require  easy 
access/modification  coupled  with  the  necessity  to  be  reloaded  without 
interruption  or  with  minimal  interference  to  the  on-going  processes. 
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As  described  in  paragraph  4.3,  these  capabilities  have  already 
been  assigned  to  the  nodal  processor  due  to  the  requirements  of 
providing  adequate  software  development  capabilities.  Continuing 
advantage  can  be  taken  of  the  up-to-date  storage  techniques,  such  as 
the  floppy  disk,  and  of  program  load  capabilities  for  program 
enhancement. 

3. 2. 2.3  Access  Processor  Functions 

Due  to  the  continuous  and  rapid  digital  bit  stream  serviced  by 
the  subscriber  interface,  (bi-directional  device  rates  up  to  50  Kbps) 
it  was  necessary  to  consider  physical  partitioning  into  two  separate 
processors  similar  to  link  processing.  Early  investigations  of  a 
serial  configuration  introduced  inter-communications  complexity  and 
system  contention  in  accessing  a common  memory.  The  proposed  design 
offers  the  functional  separation  shown  in  the  architecture  of  Figure 
3-1  and  is  based  on  the  separation  of  data  from  its  requisite  control, 
for  Class  I processing t This  requires  separate  Class  I and  Class  IX 
processors,  as  shown,  with  each  processor  given  a method  of  ingress 
and  egress  to  the  common  nodal  data  bus  via  the  separate  Class  I and 
Class  II  memory  structure  and  DMA  controller.  The  details  of  this 
hardware  are  described  elsewhere  in  this  study. 

The  resultant  software  structure  controls  the  real-time  flow 
of  the  digitized  data,  which  it  never  directly  "sees",  by  manipulation 
of  the  required  control  for  that  data  in  the  form  of  buffer 
addressing.  Real-time  hardware  data-byte  processing  permits  the  Class 
I processor  to  manage  local  subscriber  calls  in  a manner  similar  to 
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on-net  calls.  Additionally/  independent  “class"  processing  permits 
simultaneously  with  Class  1,  the  processing  of  all  Class  II  data 
terminals  attached  to  the  Class  II  processor.  This  degree  of 
simultaneity  appears  essential  to  avoid  the  potential  congestion 
represented  by  multiple  links  addressing  a single  node.  Due  to 
subscriber  access  interfacing/  parallel  processing  of  bi-directional 
input  and  output/  as  found  at  the  link  level/  is  difficult  and  costly. 
Processing  relief  is  given  instead/  at  the  access  level/  by  parallel 
processing  of  Class  I and  Class  XI  data  with  a substantial  amount  of 
real-time  hardware  for  Class  I processing. 

3. 2. 2. 3.1  Class  I Processor  - The  functions  performed  by  this 
processor  include  the  following: 

a.  Class  I Buffer  Management  - Classmate  processing  and 
subscriber  buffer  allocation  based  on  10  msecs 

b.  Routing  - Outgoing  link  selection  via  routing  table 

c.  Class  I DMA  Control  - Class  I buffer  address  transfers 
by  CHAfroa various  port  data  Memories 

d.  Local  subscriber  supervision/signaling  scan  and  control 

e.  Local  Subscriber  Switching  - Address  manipulation  of 
Class  I memory  to  create  a cross-connected 
bi-directional  data  flow. 

3. 2. 2. 3.2  Class  II  Processor  - The  functions  performed  by  this 
processor  include  the  following: 

a.  Class  II  Buffer  Management  - Similar  to  Phase  1/  30  word 
blocks  “will  be  raanagedHaiTa  free  list  memory  resource 
for  dynamically  processing  generated  outgoing  packets 

b.  Routing  - Outgoing  link  selection  resulting  from 
internal  processing  and  buffer  address  transfer 
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| j-  c.  CCIS  Generation/Analysis  - Outgoing  "call  initiate* 

| | message  types  and  initiation  of  Class  I processes  for 

| received  packets 


d.  Packetizinq  and  Depacketizing  - May  be  combined  with 
message  assembly  function  for  device  specific  buffers 
based  on  terminal  rate.  Packetizing  routines  will 
utilize  Class  XI  access  memory  free  list  buffers  for 
packet  generation 

e.  Class  II  DMA  Control  - Class  II  buffer  address  transfers 
by  DMA  from  various  port  data  memories 

f . Class  I/II  "Dummy"  Message  Header  Generation/Control  - 
Generation  of  table-driven  Class  I and  Class  II 
simulated  traffic  by  console  request  processing. 

The  Class  II  processor  has  separate  provision  for  an  I/O 
console  (perhaps  teletype)  as  discussed  earlier  under  the  nodal 
processor.  Provision  to  experimentally  vary  the  network  traffic  is 
made  possible,  at  minimum  hardware  subscriber/interface  cost,  by 
inclusion  of  a predetermined  table  of  data  (bit)  patterns . Table 
generated  voice  and  data  calls  may  be  utilized  to  explore  important 
system  parameters,  (e.g.,  full  frame  loading,  traffic  mix,  large 
message  transfer)  and  the  corresponding  system  behavior.  Since  it  was 
desired  to  permit  full  time  availability  of  the  nodal  I/O  console  for 
statistics,  report  generation  and  system  monitoring,  a second  I/O 
console  is  provided  on  the  Class  II  processor  for  generation  of 
experimental  traffic  reguests. 

The  software  elements  described  herein  for  the  SENET-DAX  model 
provide  modular  functional  partitioning  and  thus  avoid  the 
complexities  and  disadvantages  of  a large  system  executive.  This 
distribution  extends  the  characteristics  of  configuration  flexibility, 
graceful  degradation  and  higher  diagnostic  resolution  achieved  in  the 
Phase  I approach  to  the  conceptual  model.  When  considered  in  concert 
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with  the  hardware  structure * it  is  expected  to  yield  higher 
performance  and  more  flexibility  for  a given  cost  than  other 
alternative  designs  considered  by  this  study. 


3.2.3  Comparison  with  Phase  I Model 

The  recommended  model  design  configuration  differs  some  from 
the  Phase  X study  result*.  A central  difference  is  the  absence  of  the 
nodal  overflow  memory  and  the  resulting  third  level  bus.  These 
elements  which  were  used  in  the  Phase  I system  to  store  unusually  high 
busy  hour  traffic*  were  not  incorporated  because  the  study  model 
maximum  traffic  level  has  been  considered  in  the  sizing  of  the  link 
data  memories. 


For  laboratory  implementation  of  the  current  design*  single 
thread  elements  will  not  be  made  redundant.  The  elements  concerned 
are  the  nodal  processor*  the  two  level  bus  structure#  the  system 
clock*  and  routing  tables.  Before  the  system  can  be  removed  from  the 
laboratory  environment  to  an  operational  environment*  redundant  backup 
for  the  single  thread  elements  will  have  to  be  considered. 

An  elapsed  time  clock  has  been  added  to  allow  processing 
elements  to  measure  the  time  required  for  various  traffic  and  control 
procedures.  Procedural  measurements  are  given  to  the  nodal  processor 
for  statistical  correlation  and  presentation  at  the  system  console. 
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ht  the  access  level,  the  experimental  design  separates  the 
synchronous  Class  I subscribers  fro*  the  asynchronous  Class  II 
subscribers  with  a microcomputer  serving  each  class.  This  differs 
from  the  Phase  I recommendation  of  an  approach  that  suggested  the  use 
of  a low-cost  microprocessor  for  each  termination.  Additional 
development  effort  would  be  required  to  supplement  the  Phase  I study 
recommendation  in  the  most  economical  manner. 
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3.3  BASIS  OP  CHOICE  FOB  THE  DESIGN*  SELECTION 
3,3.1  Design  Considerations 

The  approach  taken  in  choosing  the  distributed  system 
architecture  was  intentionally  iterative.  Initial  and  repeated 
attemps  were  made  to  place  a maximum  burden  on  operational  software. 
These  efforts  to  minimize  special  hardware  designs  and  produce  a 
universally  versatile  programmed  system  were  often  frustrated  by  the 
complexity  of  the  many  input/output  protocols  required  by  the  dynamic 
SEPET-DAX  concept.  As  a result#  the  selected  system,  design  uses  some 
specialised  input/output  hardware  with  supervisory  processor  control. 

The  speed  and  complexity  of  a single  full-duplex  trunk  link 
presents  a significant  challenge  to  any  processor.  A full-duplex 
trunk  link  at  230.4  Kb/s  requires  an  input  or  output  byte  transfer 
approximately  every  17.5  usee.  This  real-time  operational  constraint 
is  compounded  by  a multi-faceted  link  protocol.  A complex 
star  t-of-, frame  (SOF)  flag  detection  algorithm  requires  a bit  time 
completion#  while  SOF  production  allows  byte  timing  and  the  involved 
SOF  correlation  procedure  may  be  performed  during  the  10  millisecond 
frame  period. 

The  Class  II  portion  of  the  frame  field  represents  a similar 
challenge  to  a processor.  An  output  transmission  sequence 
contiguously  includes  a Class  II  flag,  packet  destination  address# 
sequential  transmission  packet  number#  and  packet  text.  Following  the 
transmission  of  the  leading  Class  II  flag  the  processor  must  develop 
or,  a bit-by-bit  basis#  via  a complex  algorithm,  a 16-bit  Cyclic 
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Redundancy  Code  Check  (CRCC)  error-checking  word.  The  inverte  CRCC 
is  appended  to  the  packet  text  and  followed  by  a closing  Class  II 
flag.  Concurrent  with  these  activities*  the  processor  must  search  all 
data  between  Class  II  flags  to  identify  any  grouping  of  five 
contiguous  "1"  bits  after  which  a "0"  bit  must  be  inserted.  This  "bit 
stuffing"  eliminates  the  possible  appearance  of  a false  Class  II  flag 
(logically*  01111110)  during  a packet  transmission. 

A received  Class  II  portion  of  the  frame  field  represents  a 
greater  challenge  to  a processor.  Detecting  the  Class  II  flag*  which 
identifies  the  starting  bit  of  the  bit  stuffed  packet,  requires  a 
multi-step  algorithm  execution  during  a bit  time.  After  detecting  the 
Class  II  flag  the  processor  must  destuff  the  serial  stream  while 
simultaneously  developing  a CRCC.  If  the  CRCC  word  is  all  zeros 
during  the  same  bit  time  that  the  packet  ending  Class  II  flag  is 
detected  (parallel  algorithm) * the  received  packet  is  considered 
valid; 


During  the  performance  of  the  link  protocol  procedures*  the 
processor  must  also  perform  many  other  non-trivial  tasks.  Incessant 
link  input/output  byte  transfers  to  and  from  memory  are  directed  by 
tables  containing  the  starting  address  and  byte  count  length  of  each 
packet.  These  tables  require  organizing  and  constant  modifying 
attention.  The  generation  and  analysis  of  Class  II  packets  with  the 
associated  routing  procedures  consume  much  processing  time.  The 
following  section  contains  a detailed  presentation  of  the  background 
processing  routines. 
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It  is  quickly  recognized  that  special  input/output  hardware 
could  perform  many  of  the  severe  Link  interfacing  timing  requirements 
more  efficiently  than  a processor.  Placing  DMA  mechanisms,  SOF  and 
Class  II  flag  control,  CRCC  circuits  and  bit  stuffing  into  the  link 
input/output  hardware  allows  the  link  processor  to  operate  in  a 
supervisory  mode. 


Even  after  removing  the  severe  bit  time  operational  demands 
from  the  immediate  control  of  the  link  processor,  a significant 
processing  load  exists.  Initial  attempts  to  partition  trunk  link 
processor  tasking  to  a link  controller  resulted  in  a dual  processor 
architecture  where  one  processor  (link  controller)  closely  controlled 
both  input  and  output  DMA  byte  transfers  while  managing  output  packet 
sequence  number  lists.  The  second  processor  (link  processor)  was  also 
assigned  input/output  functions  such  as  packet  generation  and 
analysis,  Class  I connection  map  management,  routing  and  control 
switching  over  the  control  bus,  link  memory  allocation,  and  output 
queue '-ig.  This  functional  partitioning  exposed  three  areas  of 
difficulty.  The  successive  byte  incremented  DMA  block  transfer 
operations  for  both  input  and  output  link  data  consumed  a great 
amount  of  processor  time,  leaving  little  time  for  packet  sequence 
number  lists  and  the  necessary  communications  with  the  link  processor. 
Interprocessor  communication  between  the  link  controller  and  link 
processor  represented  a major  limiting  factor  in  the  operational 
viability  of  this  dual  processor  link  port  architecture.  The  amount 
of  interprocessor  data  necessary  and  the  slow  rate  of  transfer 
available  would  have  resulted  in  link  data  input/output  delays. 


Finally,  the  large  processing  load  placed  on  the  link  processor  would 
have  resulted  in  an  impossible  processing  load* 

As  shown  in  Figure  3-2  and  the  following  paragraph  on  software 
timing,  the  recommended  design  configuration  separates  link  input  and 
output  functions  for  control  by  individual  microcomputers.  This 
functional  partitioning  minimizes  link  input  and  output  processor 
intercommunications,  still  utilizes  a high  percentage  of  processor 
time,  but  represents  the  most  efficient,  cost-effective,  and  viable 
option.  This  functional  arrangement  closely  resembles  the  processor 
architecture  recommended  in  Phase  I. 

At  the  access  port  a dual  processor  architecture  is  also 
required.  The  functional  partitioning  separates  Class  I and  Class  II 
tasks  with  their  respective  synchronous  and  asynchronous  terminals. 
Similar  to  that  described  above  for  link  port  processing,  an 
evolutionary  process  which  initially  utilized  an  access  controller  and 
access  processor  concluded  with  the  Class  I and  Class  II  processors. 
The  subscriber  terminal  speed  buffering  with  the  multiplicity  of  Class 
I subscriber  type  signaling/supervision  and  rate  servicing 
requirements,  presented  an  impossible  task  for  direct  processor 
servicing.  Therefore,  special  input/output  hardware  directly  controls 
the  Class  I subscribers  under  the  control  of  the  Class  I processor. 

In  view  of  the  small  quantity  and  low  asynchronous  rate  of  anticipated 
Class  II  subscribers,  the  access  port  can  be  interfaced  to  the  nodal 
bus  directly  thrugh  a Class  II  processor. 


3.3.2  Timing  Analysis 


3. 3. 2.1  General 

The  timing  analysis  for  the  input  processor  operational 
program  has  taken  into  account  both  the  time  critical  requirements  of 
input  processing*  and  the  need  for  a secondary  processor  scan.  This 
has  resulted  in  a link  input  processor  structure  which  is  partitioned 
into  a real-time  (foreground)  and  scan  (background)  mode.  All  real- 
time processing  will  be  under  the  control  of  the  Real-Time  Interrupt 
program.  Processing  of  the  interrupt  will  be  kept  to  a minimum,  with 
input  information  stored  in  data  buffers  for  later  background  scan 
processing.  All  tasks  that  can  be  delayed  or  performed  on  a 
background  scan  basis  are  scanned  by  the  Control  Scheduler  program. 

It  is  this  program  which  will  cycle  through  each  of  the  background 
scan  subprograms  allowing  individual  task  processing  to  be  done. 

The  two  major  processing  areas  (interrupt  servicing  and 
control  scheduling)  in  the  link  input  processor  operational  software 
are  discussed  below.  The  interrupt  driven  program  structure  permits 
more  efficiency  and  minimizes  the  program  loading  on  the  processor  due 
to  software  scanning. 

3. 3. 2. 1.1  Real-Time  Clock  Interrupt  ~ A real-time  clock  function  has 
been  assumed  for  purpose  of  this  analysis,  with  this  function 
initiating  control  address  transfers  for  storage  of  input  voice  and 
data.  The  clock  interrupt  rate  is  1 msec  which  approximates  the  time 
required  to  store  an  incoming  packet. 
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The  large  number  of  interrupts/sec  (determined  on  a 1 ms  basis 


to  be  1000  interrupts/sec)  underlies  the  need  for  efficient  and 
compact  software  coding  of  these  routines. 

3. 3. 2. 1.2  Control  Scheduler  Program  - All  background  processing  for 
the  Line  Input  Processor  will  be  under  the  direct  command  of  the 
Control  Scheduler.  Its  function  is  to  sequentially  scan  through  its 
task  queue  polling  each  subprogram  for  activity.  When  activity  is 
requested,  the  control  scheduler  will  call  the  responsible  subprogram 
for  processing. 

The  following  task  subprograms  will  be  called  by  the  Contol 
Scheduler  during  a background  scan  and  form  the  basis  for  the 
following  timing  estimates? 

a.  Free  memory-list  management 

b.  Packet  analysis 

c.  Transmit  packet  control 

d.  Ack/No  Ack  processing 

e.  Maintenance 

f.  Statistics. 

3. 3. 2. 2 Link  Input  Processor  Timing 

The  timing  analysis  has  been  performed  for  the  sub  task 
elements  of  the  control  scheduler  in  the  Link  Input  Processor.  The 
assumptions  which  were  made  for  the  timing  analysis  are  itemized  in 
Appendix  I. 
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All  calculations  ace  also  shown  in  Appendix  I and  are 
summarized  in  Table  3-1  contained  in  this  section. 

The  basic  plan  in  this  analysis  was  to  identify  the  time 
critical  processor  requirements  in  the  Link  Input  processing.  Hence 
the  operational  software  is  broken  into  a real-time  processing  element 
and  a control  scheduler  element y the  purpose  being  to  minimize  the 
timing  on  the  interrupt  routine.  The  important  loading  functions  are 
discussed  below  in  order  of  time  dependence. 

3. 3. 2. 2.1  Real-Time  Interrupt  Timing  - Packet  storage  requirements 
have  indicated  that  a 1 ms  interrupt  cycle  will  be  used.  This  means 
that  there  will  be  1000  interrupts/second  which  must  be  processed. 
Analysis  has  shown  that  a 5j0  instruction  interrupt  handling  routine 
should  be  considered.  The  processing  loading  as  figured  on  a 1000  ms 
(1  second)  capacity  is  calculated  to  be  160  ms  or  16  percent  processor 
loading.  The  high  number  of  interrupts/second  shows  the  need  to 
minimize  the  size  of  the  interrupt  processing  routine. 

3. 3. 2. 2. 2 Control  Scheduler  Timing  - Scan  requirement  estimates  show 
that  a 4 ms  background  scan  is  required  to  set  up  the  processing  of 
operational  software  background  routines.  An  analysis  of  the  maximum 
number  of  executed  instructions  on  a loop  scan  found  that  100 
instructions  would  be  required.  This  results  in  a 78  ms  execution 
time  or  7.8  percent  link  input  processor  loading. 

3. 3. 2. 2. 3 Free  Memory  Background  List  Management  - The  timing  impact 
of  list  management  has  been  considered  using  the  maximum  number  of 
addresses  which  may  be  processed  in  a given  scan.  Using  the  absolute 
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maximum  of  500  input  packets/1 ink,  the  average  number  of  addresses 
required  would  be  250  transfer  addresses.  The  routine  is  anticipated 
to  consist  of  an  overhead  portion  of  sequence  setup  followed  by  a loop 
list  process.  The  execution  of  free  list  processing  results  in  at 
most  a 22.5  ms  or  2.25  percent  loading  of  the  processor  which  is  not 
significant.  The  speed  of  the  individual  scan  (that  is  the  number  of 
instructions}  must  be  kept  low  so  as  to  minimize  processor  loading. 

3. 3. 2. 2. 4 Packet  Analysis  Timing  - For  this  calculation  a figure  of 
500  packets/sec  was  considered  an  absolute  maximum  of  the  Class  II 
traffic  per  link.  The  longest  potential  processing  loop  of  the 
analysis  routine  has  been  estimated  to  be  200  instructions.  The 
result  of  this  processing  is  a 300  msec  processor  time  or  a 30  percent 
loading  on  the  processor.  This  large  loading  indicates  the  importance 
of  this  aspect  of  the  processing  and  careful  attention  should  be  paid 
to  its  organization  in  the  final  design* 

3. 3. 2. 2. 5 Translation  and  Routing  Timing  - Although  these  routines 
are  called  as  subroutines  and  are  not  directly  involved  in  the 
background  processor  scan,  their  timing  impact  should  be  measured  when 
taking  into  consideration  the  total  link  input  processor  loading.  We 
consider  that  all  data  packets  will  .be  translated  and  routed  prior  to 
control  switching  to  another  link.  The  calculation  in  the  table  shows 
that  the  total  impact  will  be  less  than  10  percent  loading. 

3. 3. 2. 2. 6 Transmit  Packet  Control  Timing  - After  a CCIS  or  data 
packet  has  been  set  up  and  formatted,  control  information  for  the 
packet  must  be  transmitted  to  the  output  link  processor.  In  the  worst 
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case,  a maximum  of  500  packets/sec  will  have  to  have  control 
information  transferred.  The  subroutine  to  do  this  is  estimated  to  be 
40  instructions  in  length,  but  the  impact  of  300  packets/sec  results 
in  a 6 percent  loading  just  for  one  task. 

3. 3. 2. 2. 7 Acknowledge/No  Acknowledge  Timing  - Timing  for  the  absolute 
maximum  case  considers  that  500  packets/sec  will  have  to  be 
acknowledged  when  they  are  processed  by  the  Link  Input  processor. 

This  timing  analysis  does  not  consider  the  timeout  monitoring  that  is 
taking  place  whenever  a packet  is  transmitted  from  the  output 
processor.  This  will  be  examined  in  the  timing  analysis  of  the  Link 
Output  Processor.  The  processor  loading  on  the  basis  of  a maximum  of 
500  packets  (per  link)  is  determined  to  be  7.5  percent. 

3. 3. 2. 2. 8 Maintenance  and  Statistics  - This  routine  is  the  lowest 
level  of  time  importance  but  the  great  number  of  instructions 
anticipated  for  the  function  indicate  that  there  is  a loading  effect 
on  the  processor.  On  the  basis  of  estimated  requirements  it  has  been 
assumed  that  200  instructions  will  be  executed  in  the  worst  background 
maintenance  and  statistics  case.  This  is  equivalent  to  a 6 percent 
loading  figure. 

3. 3. 2. 2. 9 Link  Input  Processor  Timing  Conclusions  - Processor  loading 
for  an  absolute  maximum  per  link  of  500  packets/second,  and  .13  CCIS 
calls/sec  is  calculated  to  be  78.8  percent.  This  seems  like  high 
loading  but  it  must  be  emphasized  that  the  peak  traffic/link  condition 
is  assumed.  For  an  average  busy  hour  condition  of  200  packets  per 
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link,  the  processor  loading  drops  down  to  46  percent.  Table  3-1  is  a 
summary  of  the  calculations  of  these  traffic  conditions. 

3. 3. 2. 3 Link  Output  Processor 

Similar  to  the  Link  Input  Processor,  the  design  of  the  LOP 
considers  the  time  critical  sequences  of  processing  the  Class  1 and 
Class  II  messages.  Thus  the  link  output  structure  is  partitioned  in  a 
real-time  scan  and  background  scan  mode.  All  real-time  processing  is 
considered  to  be  under  the  control  of  the  Real-Time  Interrupt  program 
for  purpose  of  this  analysis.  The  technique  and  requirements  used  for 
the  Real-Time  Clock  routine  will  be  the  same  as  previously  discussed 
for  that  of  the  Link  Input  Processor. 

All  tasks  that  can  be  performed  on  a background  scan  basis  are 
scanned  by  a Control  Scheduler  program.  Each  of  the  two  major 
processing  areas  in  the  LOP  software  are  discussed  below. 

3. 3. 2. 3.1  Real-Time  Clock  Interrupt  - This  routine  is  entered  via  a 
1ms  clock  interrupt.  Comparable  to  the  interrupt  processing  for  the 
Link  Input  Processor,  the  service  routines  process  the  requisite 
control  information  for  the  real-time  transfers  from  the  link  data 
memory. 

3. 3. 2. 3. 2 Control  Scheduler  Program  - Like  the  input  processor,  all 
background  processing  for  the  LOP  will  be  under  the  direct  command  of 
the  Control  Scheduler.  The  function  of  the  Control  Scheduler  is  to 
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scan  sequentially  through  its  task  queue  polling  each  subprogram  for 
activity.  When  activity  is  requested,  the  Control  Scheduler  will  call 
the  responsible  subprogram  for  processing. 

The  following  task  subprograms  will  be  called  by  the  Control 
Scheduler  during  a background  scan  and  form  the  basis  for  the 
following  timing  estimates. 

a.  Free  memory-list  management 

b.  Background  queue  entry/transmit  queue  processing 

c.  Timeout  processing 

d.  Output  address  generation 

e.  Process  delete  channel  message 

f.  Maintenance  statistics. 

3. 3. 2. 3. 3 Link  Output  Processor  Timing  - The  timing  analysis  has  been 
performed  for  the  time  critical  elements  of  the  Link  Output  Processor. 
All  calculations  are  shown  in  Table  3-2.  A number  of  timing 
techniques  common  to  both  the  input  and  output  routines  have  not  been 
re-includad  in  this  paragraph. 

3. 3. 2. 3. 4 Free  Memory  Backgrund  List  Management  - Refer  to 
paragraph  3. 3. 2. 2. 3 for  discussion  of  list  management  timing 
requirements. 

3. 3. 2. 3. 5 Background  Queue  Entry/Transmit  Queue  Processing  - For  this 
calculation  a figure  of  500  packets/sec  was  considered  as  an  absolute 
maximum  for  the  Class  II  traffic  per  link.  It  has  been  determined 
that  the  routine  to  process  the  allocation  of  the  incoming  packets  to 
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the  appropriate  csueue  will  take  an  estimated  maximum  of  60 
instructions*  This  results  in  a software  impact  of  90  ms  on  the 
output  processor  or  s 9 percent  processor  loading. 

3.3. 2.3.6  Timeout  Processing  - The  impact  of  this  routine  is 

dependent  on  the  number  of  packets  per  second  which  are  received 
incorrectly  and  allowed  to  time  out.  This  number  is  dependent  on  the 
particular  burst  error  rate  (BER)  of  the  transmission  media:  ice., 

for  a B£F?  of  Iff5  and  a packet  size  of  224  bits,  only  1.1  packets/sec 
ace  in  error,  whereas  for  a BER  of  at  least  100  packets/sec  are 

in  error.  However,  due  to  the  small  number  of  instructions  to  process 
a timeout,  the  processor  loading  of  2 percent  at  maximum  is  not  a 
significant  factor. 

3. 3. 2. 3. 7 Output  Address  Generator  - The  maximum  link  constraint  of 
500  packets  per  second  results  in  a 6 percent  load  inn  impact  due  to 
the  fact  that  this  routine  is  called  repetitively. 

3. 3. 2. 3. 8 Maintenance  and  Statistics  - Refer  to  the  discussion  in 
paragraph  3. 3. 2. 2. 8 on  Kaintenance  Statistics. 

3. 3. 2.3.3  Link  Output  Processor  Timing  Conclusions  - Processor 
loading  for  an  absolute  maximum  per  link  of  500  packets/second  and  .13 
CCIS  calls/sec  is  calculated  to  be  47,7  percent.  For  an  average 
condition  of  200  packets  per  link,  the  processor  loading  decreases  to 

33.8  percent.  Table  3-2  is  a summary  of  the  calculations  of  these 
traffic  conditions. 
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3. 3. 2. 4 Summary  of  Timing 


A timing  analysis  of  the  Link  Input  Processor  and  the  Link 
Output  Processor  has  been  presented.  The  figures  are  herein 
summarized  for  the  peak  and  average  busy  hour  cases  below.  The 
reserve  requirement  for  future  program  expansion  was  set  at  25 
percent. 


TABLE  3-3.  TIMING  SUMMARY:  LINK  INPUT  PROCESSOR 

AND  LINK  OUTPUT  PROCESSOR 

PEAK  TIMING  AVERAGE 

500  PACKETS/SEC  200  PACKETS/SEC 


PERCENT 

PERCENT 

Link  Input  Processor 

78.8 

46.2 

LIP  Reserve 

25.0* 

25.0 

Link  Output  Processor 

47.7 

33.8 

LOP  Reserve 

25.0 

25.0 

*It  should  be  noted  that  the  Link  Input  Processor  loading  does  not 
allow  a 25  percent  reserve  reguirement.  The  actual  forced  reserve 
reguirement  is  21.2  percent. 

The  above  information  is  useful  in  determining  the  impact  of 
various  architectures  on  the  DAX  timing.  In  particular,  a discussion 
of  the  Central  Processor  approach  is  evaluated  below. 

The  basic  characteristic  of  the  C.  P,  approach  is  the 
combination  of  the  Link  Input  Processor  and  the  Link  Output  Processor. 
In  addition  an  access  switch  will  be  integrated  into  the  C.  P. 
requirements.  Combination  of  the  LIP  and  LOP  reduces  software 
duplication,  but  on  the  other  hand  the  traffic  peak  handled  by  the 
processor,  and  its  average  offered  traffic,  increases  greatly. 
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3.  3. 2. 5 Central  Pro-ccc''',~Tir-uCt;  on  Duplication 


It  is  not. *3  that  there  are  a number  of  routines  which  can  be 
considered  common  to  both  input  and  output  processing.  These  include 
the  following: 


a.  Real-Time  Clock  Interrupt  Routine 

b.  Control  Scheduler 

c.  Free  Memory/List  Management 

d.  Maintenance  and  Statistics 


8. 0 percent 
3. 9 percent 
2. 2 percent 

6. 0 percent 


Total 


20.1  percent 


In  addition  the  transmit  Packet  Control  (with  6.0  percent  loading)  in 
the  Link  Input  Processor  will  not  be  necessary  since  the  same 
processor  does  Input  and  Output:  therefore,  no  interface  routine  is 

necessary.  Hence  the  total  impact  of  the  Central  Processor  Approach 
is  a total  decrease  of  26  percent. 


The  combined  impact  timing  is  considered  in  Table  3-4.  It  is 
evident  that  with  a peak  packet  load  the  requirements  of  loading  on 
the  processor  exceed  its  capacity.  Even  with  an  average  busy  hour 
packet  figure  of  200  packets/sec,  the  loading  using  the  combined 
effects  jumps  18  to  31  percent  over  the  distributed  approach  for  the 
3-link  model  under  consideration. 


It  must  also  be  kept  in  mind  that  the  summary  timing  of  Table 
3-4  does  not  include  estimates  for  the  interrupt  processing  required 
by  the  access  subscribers.  One  method  of  evaluating  the  viability  of 
the  central  processing  approach  is  to  consider  the  impact  of  this 
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access  processing  load.  An  interrupt  service  routine  must  complete 
servicing  of  all  subscribers  in  less  than  160  ''sec  since  this  is  the 
byte  transfer  rate  for  one  KY3-50  kilobit  line.  Since  the  service 
time  for  up  to  12  subscribers  would  require  about  90  usee  to  check  and 
store  all  input  bytes,  only  70  ysecs  or  44  percent  of  the  total 
processor  time  would  be  available  for  processing.  Reference  to  Table 
3-4  indicates  that  64.2  percent  is  required  to  be  available  for 
average  busy  hour  processing  and  thus  the  single  processor  would  be 
overloaded  by  addition  of  the  access  subscriber  scanning  function. 


3.4  DETAILED  HARDWARE  DESIGN  FOR  COST  ESTIMATES 


The  detailed  hardware  designs  shown  in  Figures  3-3  and  3-4 
provide  a firm  basis  in  estimating  hardware  costs.  Each  processor  is 
shown  with  program  memory  and  a peripheral  input/output  bus.  Attached 
to  the  peripheral  buses  are  parallel  line  interface  (PLI)  and  serial 
line  interface  (SLI)  modules.  An  SLI  provides  an  asynchronous 
interface  from  a processor  to  a teletype  or  other  data  terminal 
device.  A PLI  allows  a multi-bit  parallel  input  or  output  with 
peripheral  handshaking,  strobed  by  an  appropriate  nodal  clock  phase. 

All  port  data  memories,  which  together  comprise  the  total 
nodal  memory  on  one  data  bus,  are  surrounded  by  clock  selected  address 
and  data  gating  circuits.  Incoming  data  from  a link  or  access 
terminal  is  given  X clock  phases  for  data  storage,  the  data  bus  is 
allowed  at  least  X clock  phases  for  data  extraction,  and  the 
appropriate  memory  management  port  processor  is  provided  X clock 
phases  for  read  or  write  operations.  A comparator  is  associated  with 
every  port  memory  to  monitor  the  upper  three  bits  on  the  address 
portion  of  the  data  bus.  When  an  address  appears  on  the  bus  which 
requires  data  from  a particular  port  memory,  the  port  comparator 
enables  tri-state  bus  driving  buffers  to  transmit  the  requested  data. 

An  elapsed  time  clock  is  given  a periodic  clock  phase  to 
propagate  incremented  a 16-bit  time  refers,  onto  a portion  of  the 
28-bit  data  section  of  the  control  bus.  . nen  a processor  is  commanded 
to  statistically  analyze  a control  operation,  a snap-shot  reading  of 
this  clock  at  the  initiation  and  conclusion  of  the  operation  provides 


3-35 


<u 

u 

ft] 

>d 

u 
r a 


It] 

c 

o 

•H 

+) 

0 

c 

3 

fa 

l-i 

0) 

T3 

1 


Q 

1 

Em 

W 

2 
fa 
CO 


• 

01 

I 

n 

0) 

M 

3 

O' 

•H 

fa 


3-36 


Figure  3-4.  Class  I Subscriber  Access  Subsystem 


the  relative  information  needed  to  quantize  the  operational  time 
consumed.  Based  on  the  maximum  trunk  link  rate  of  230.4  Kb/s,  the 
elapsed  time  clock  resolution  is  about  34.7  sec  with  a maximum  window 
time  of  approximately  2.27  seconds. 

The  routing  table  is  updated  periodically  only  by  the  nodal 
processor#  gated  by  the  nodal  clock  phase  1.  Therefore#  the  routing 
table  read/write  line  is  also  controlled  by  phase  1 to  allow  a read  or 
write  during  that  phase  and  only  a read  operation  at  all  other  times. 

Previous  sections  of  this  report  explain  nodal  processor 
functions#  link  port  hardware  and  processing  operations#  and  access 
port  processing  with  Class  II  data.  The  following  paragraph  describes 
the  hardware  operations  in  the  Class  I subscriber  access  subsystem. 

3.4.1  Class  I Subscriber  Access  Subsystem 

The  purpose  of  this  paragraph  is  to  describe  the  operation  of 
the  SENET-DAX  Class  I Subscriber  Access  Subsystem.  First,  access 
requirements  will  be  determined  for  this  scaled  down  version  of  the 
Phase  1 SENET-DAX.  Then  the  functional  hardware  will  be  described# 
including  a byte  by  byte  description  of  data  transfer.  Finally#  the 
subscriber  capacity  of  the  access  subsystem  will  be  discussed. 

In  order  to  demonstrate  SENET-DAX  concepts,  requirements  for 
the  Class  I subscriber  access  subsystem  have  been  set.  The  subsystem 
must  be  able  to  input  digital  subscribers  at  synchronous  data  rates 
between  2#  4 Kbps  and  50  Kbps.  To  have  a reasonable  representation  of 
subscribers  in  this  range  and  to  illustrate  the  workability  of  the 
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SENET-DAX  concept,  the  following  typical  distribution  of  subscriber 
terminals  has  been  considered. 


Cuantitj 


Terminal  Type  Data  Rate 
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CVSD  VOICE 


CVSD  VOICE 


FACSIMILE 


VOCODER 


50  Kbps 
32  Kbps 
16  Kbps 
9.6  Kbps 
2.3  Kbps 


11  TOTAL 


The  Class  I subscriber  access  subsystem  must  be  able  to 
service  the  Class  I data,  supervision  and  signaling  at  the  11  typical 
multi-rate  subscriber  terminals  listed  above.  The  supervision  and 
signaling  techniques  that  interface  with  the  access  subsystem  include 
dual  tone  multifreguency,  tone-on-idle,  dial-pulse  and  digital 
codewords. 

To  service  the  above  requirement,  a proposed  Class  I 
subscriber  access  subsystem  is  shown  in  Figure  3-4.  The  subsystem 
consists  of  Class  I access  memory,  supervision/signaling  hardware,  and 
access  hardware.  The  access  memory  is  subdivided  into  four  blocks  of 
512  bytes  each  (B,C,D,E).  This  block  grouping  is  based  on  the  maximum 
amount  of  data  that  can  be  transferred  in  one  direction  between  the 
nodal  bus  and  the  11  suscriber  terminals  in  10  milliseconds  (288  bytes 
rounded  up  to  the  most  significant  bit).  The  access  memory  is  also 
grouped  into  two  1024-byte  blocks.  Each  of  these  blocks  is 


alternately  accessed  from  either  the  nodal  data  bus  (by  0 , X,  Y and  Z) 
or  the  access  hardware.  The  start-of-frame  (SOF)  flag  toggles  a 
flip-flop  which  gates  the  address  and  data  lines  of  the  access 
hardware  or  nodal  bus  to  an  alternate  1024-byte  block  of  Class  I 
access  memory  every  10  milliseconds.  Assume  for  the  moment  that  the 
access  hardware  has  access  to  memories  D and  E.  The  line  termination 
subsystem  (LTS)  interfaces  the  digital  subscribers  with  the  serial 
line  interfaces  (SLI)  and  the  supervision/signaling  hardware.  The  LTS 
separates  data  from  signaling/supervision  for  each  subscriber 
terminal.  The  supervision/signaling  hardware  interfaces  with  the 
Class  X processor  for  control. 

Once  signaling  and  supervision  are  processed  and  a connection 
is  made  between  two  subscribers,  the  LTS  gates  Class  I data  from  a 
subscriber  terminal  to  a corresponding  SLI.  The  SLI  is  a full-duplex 
synchronous  serial-to-parallel  converter  that  is  supplied  with  a clock 
rate  that  is  the  same  as  the  terminal  rate  which  it  services.  The  SLI 

i 

is  double  buffered  to  hold  an  incoming  byte  for  1 byte  time.  Upon 
receiving  eight  bits  of  serial  data  the  SLI  generates  a flag.  The 
flag  from  each  SLI  is  presented  to  a priority  interrupt  controller 
(PIC). 


7 


The  subscriber  data  rate  at  which  a SLI  operates  determines 
the  servicing  priority  assigned  to  Its  SLI  flag.  Servicing  priority 
is  assigned  as  follows: 


Data  Rate 


Priority 


50  Kbps 
32  Kbps 
32  Kbps 
32  Kbps 
32  Kbps 
16  Kbps 
16  Kbps 
16  Kbps 
16  Kbps 
9.6  Kbps 
2.4  Kbps 


highest 


lowest 


The  PIC  acknowledges  the  highest  priority  interrupt  and  masks 
out  all  lower  priority  interrupts  until  the  highest  priority  interrupt 
is  serviced. 


The  priority  interrupt  results  in  a complete  Class  I access 
memory  cycle.  Initially  the  address  table  contains  a starting  address 
and  frame  time  byte  count  for  each  subscriber.  The  byte  count  for 
each  terminal  is  the  number  of  bytes  of  storage  that  are  allocated  for 
10  milliseconds  of  subscriber  data.  The  starting  address  is  assigned 
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to  allocate  a non-overlapping  memory  block  for  each  subscriber.  Along 
with  these  quantities , a current  byte  count  for  each  subscriber  is 
kept  in  the  address  table  and  updated  after  each  access  cycle. 

A Class  I access  memory  cycle  proceeds  as  follows.  The  PIC 
first  sends  the  subscriber  terminal  number  to  the  address  controller. 
The  address  controller  looks  up  the  starting  address  and  current  byte 
count.  The  address  register  is  loaded  with  the  current  address  which 
equals  the  starting  address  plus  the  current  byte  count*  and  points  to 
a location  in  a 512-byte  input  block  of  memory  (D) . The  PIC  then 
enables  the  data-in  lines  of  the  SLI  and  stores  the  incoming  data  byte 
in  memory  D at  the  location  pointed  to  by  the  address  register.  The 
access  cycle  then  complements  the  flip-flop  MSB  to  point  to  a location 
in  output  memory  E from  which  a byte  of  output  data  is  transferred  to 
the  interrupting  SLI.  This  byte  is  serially  clocked  to  the  subscriber 
terminal.  The  preceding  process  constitutes  one  access  cycle.  The 
current  byte  count  is  now  updated,  allowing  the  next  priority 
interrupting  SLI  to  be  serviced. 

Ten  milliseconds  from  the  first  access  cycle,  the  current  byte 
count  will  equal  the  final  byte  count  for  all  serviced  subscribers. 
When  this  occurs  a SOP  flag  will  interchange  the  Class  I access  memory 
address  lines  between  memory  blocks  (B,C)  and  (D,E).  While  the  access 
hardware  is  performing  access  cycles  on  memories  B and  C,  any  link 
output  controller,  via  the  nodal  bus,  is  allowed  to  perform  block 
burst  transfers  of  data  from  B.  Simultaneously,  the  Class  I processor 
controls  similar  DMA  transfers  into  memory  C from  any  link  memory. 
Discrete  burst  transfer  rates  can  be  as  high  as  the  maximum  link  data 
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rate. 

The  above  process  is  used  exclusively  for  network  calls.  For 
the  interconnection  of  compatible  local  subscribers,  at  the  same  port, 
subscriber  data  does  not  use  access  memory.  The  CLI’s  for  the  local 
subscribers  are  connected  by  the  PIC  using  the  bus  switch  (BX)  during 
the  priority  interrupt  cycle. 
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SECTION  4 


EQUIPMENT/SOFTWARE  SURVEY  INVESTIGATION 


4.1  MINICOMPUTERS  VS  MICROCOMPUTERS 

During  the  evaluation  of  design  alternatives,  a number  of 
configurations  were  considered,  including  those  calling  for  higher 
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processing  capability  due  to  the  centralization  (and  therefore 
serialization)  of  processing.  An  early  outgrowth  of  these 
considerations  was  the  realization  that  a centralized  approach, 
utilizing  minicomputers  exhibited  difficulties  (such  as  timing  and 
memory  access  constraints,  see  paragraphs  2.4  and  2.6)  that  were  not 
offset  by  raw  speed,  floating  point  options,  comprehensive  libraries 
and  large  executive  programs  for  resource  control.  Further 
examination  also  led  us  to  conclude  that  existing  applications 
software,  offered  by  manufacturers,  could  not  be  directly  applied 
without  extensive  and  difficult  modifications.  The  main  survey  effort 
was  therefore  focused  on  the  microcomputer  field  and  the  available 
development  tools  required  by  a microcomputer  based  system. 


4.1.1  Microcomputers 

This  decade  has  seen  a rapid  proliferation  of  microcomputer 
manufacturers  within  the  semiconductor  industry,  utilizing  primarily  a 
raetal-oxide-samiconductor  (MOS)  technology.  The  ability  to  choose  an 
optimal  processor  for  a specific  application  is  complicated  by  not 
only  the  number  of  products  but  also  by  similar  claims  of  capability, 
sparse  application  notes  and  the  general  unavailability  of  user 
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evaluations  due  fco  the  infancy  of  this  new  market.  At  this  writing , 

4,  8,  12,  and  16-bit  processors  have  been  developed  with  the  8~bit 
processor  currently  dominating  the  market.  A typical 
mlcroprocessor-on-a-chip  architecture  is  shown  in  Figure  4-1.  The 
on-chip  computational  capability,  aside  from  microcode,  is  of  course 
determined  by  the  number  of  registers,  their  width  and  their 
connectivity  within  the  chips.  Figure  4-1  shows  a typical  address  and 
data  bus  arrangement  for  accessing  memory.  The  16-bife  address  bus 
gives  an  addressing  capability  of  64k  but  the  8-bit  data  bus  requires 
multiple  accesses  for  fetching  16-bit  operands  or  address  retrieval. 
These  architectural  limitations  impose  a careful  matching  of 
processor-to-application  for  efficient  problem  processing  and  require 
an  examination  of  the  software  development  tools  that  may  be  provided, 
since  these  tools  substantially  affect  the  development  time,  cost,  and 
reliability  of  the  product. 

4.1.2  Software  Characteristics 

?n  order  to  enhance  their  capability,  certain  manufacturers 
have  produced  microcomputers,  replicating  the  instruction  set  of 
existing  minicomputer  product  lines.  This  degree  of  comparability 
allows  much  of  the  sophisticated  minicomputer  support  software  to  be 
made  available  to  support  the  development  effort. 

Other  vendors  have  attempted  to  provide  their  own  basic 
assembler  programs,  both  cross  and  resident,  but  by  minicomputer 
standards  these  are  not  extensive. 
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The  development  of  a resident  language  processor  is  a 
non-trivial  task  and  it  is  not  likely  that  high  quality  language 
processors  will  be  produced  by  volume-oriented  semiconductor  vendors 
due  to  the  large  required  investment.  This  is  readily  apparent  in  the 
existing  software  now  being  offered  by  most  semiconductor 
microcomputer  manufacturers.  Most  cover  only  basic  translation 
support  (language  processor)  and  some  form  a debug  capability 
(monitor).  In  many  cases,  little  or  no  support  is  provided  for 
design,  code  and  loading  of  programs. 


According  to  Ogdin,  [14],  monitors  are  notoriously  poor  and 
oversized.  Since  size  is  an  important  measure  of  monitor  quality,  his 
rewriting  efforts  have  realized  an  increase  of  over  50  percent  in 
monitor  space.  Assemblers  also  appear  to  be  of  generally  poor  quality 

(resident),  oversized  and  error  prone.  ; 

i 

Tables  4-1,  4-2  and  4-3  summarize  three  types  of  resident  i 

I 

assembly  language  programs  available  today  for  symbolic  development  of  ; 
programs;  Table  4-1,  Assembly  Language;  Table  4-2,  Macro  Assembly 
Languages;  and  Table  4-3,  System  Implementation  Languages.  Basically 
assembly  language  is  still  the  most  efficient,  where  tight  code  and 
minimum  size  may  be  critical.  Once  the  single  assembler  is  left 
behind  in  favor  of  MAL  or  SIL  development,  less  control  is  exercised 
over  generated  code  and  is  somewhat  less  efficient.  The  tradeoff  here 

( 

is  speed  and  increased  reliability  versus  tightness  and  efficiency  of 
code. 


4-4 


4.1.3  Macro  Assembly  Language  (Table  4-2) 


Macro  capability  permits  the  generation  of  a predetermined 
number  of  machine  language  instructions  for  each  MAL  instruction. 
Capabilities  generally  vary  from  conditional  selection  of  program 
segments  to  basic  text  replacement.  This  level  represents  a step  to 
improve  the  reliability  of  the  generated  code,  reduce  its  development 
time  and  still  produce  reasonably  tight,  efficient  code.  As  such,  it 
falls  about  half  way  between  an  AL  and  a higher  level  language  and 
represents  a good  compromise.  The  Intel  MAL  offers  only  basie  text 
replacement  capability  while  the  announced  RCA  MAL  is  expected  to  have 
both  conditional  and  parametric  capability.  Motorola  is  understood  to 
be  developing  a MAL  with  significant  capability  for  the  M6800  [12]. 

4.1.4  System  Implementation  Languages  (Table  4-3) 

Microcomputer  based  SIL's  are  still  in  an  early  development 
stage  but  are  generating  high  industry  interest.  Conceptually,  a SIL 
increases  the  efficiency  of  generated  code  by  use  of  algorithmic 
representations  that  relate  to  and  take  advantage  of  the  specific 
architecture  of  the  machine.  Intel's  PLM  is  a well  known  example  of 
this  type.  The  increase  in  efficiency  is  obtained  only  with  a loss  of 
generality  with  respect  to  compatability  with  other  processors. 

Problem  areas  in  present  SIL's  include  address  arithmetic, 
resource/register  allocation  and  interrupt  handling,  but  new  machine 
architectures  may  help  to  solve  these  difficulties  in  the  future  [8]. 
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Some  industry  efforts  are  beginning  to  concentrate  on 
improving  offered  language  products  which  should  be  of  future  benefit 
to  produce  better  development  support  software . Many  products  are 
still  experimental  in  nature  with  others  nearly  primitive  in  scope. 
Early  users  must  assist  manufacturers  in  evaluation  and  are  improving 
those  versions  that  are  available  today  at  their  own  expense. 

In  light  of  the  uncertain  staying  power  or  support  committment 
of  soma  semiconductor  manufacturers,  and  the  need  for  comprehensive 
development  tools  consistent  with  processor  capability,  this  study 
effort  focused  on  two  manufacturers  that  provide  substantial  software 
support  due  to  their  compatible  minicomputer  product  lines.  This 
focus  is  consistent  with  study  guidelines  to  utilize  existing 
firmware/software  processing  modules.  Both  Data  General’s  U-Nova  and 
Digital  Equipment's  LSI-11  microprocessor  permit  proven  existing 
software  tools  to  be  directly  applied  to  the  development  of  a 
peripheral-limited  multi-microprocessor  system.  Thesa  two  products 
are  more  fully  described  in  the  following  paragraph  on  Operational 
capability. 

4.2  OPERATIONAL  CAPABILITY,  AVAILABILITY  AND  COST 

One  major  stipulated  goal  for  this  supplemental  design  study 
was  to  maximally  utilize  existing  hardware  and  software  modules  in  the 
recommended  design  configuration.  As  discussed  in  the  previous 
paragraph,  this  criterion  prevented  serious  consideration  of  any 
system  manufacturer  that  did  not  supply  a complete  hardware  family, 
extensive  software  support,  and  off-line  software  development 
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capability.  In  view  of  the. above#  and  the  limited  time  frame  for  this 
study#  the  equipment/software  survey  investigation  selected  the 
Digital  Equipment  Corporation  LSI-11  and  the  Data  General  Corporation 
UNova  microcomputer  families  for  comparative  analysis  and  evaluation 
of  their  applicability  for  the  recommended  design  configuration. 

The  LSI-11  and  jiNova  differ  considerably  in  their  central 
processor  and  microcomputer  system  architectural  approaches.  While 
the  I.SI-11  with  its  multi-chip  central  processor  units  (CPU)  places 
all  memory  # peripheral  interfaces#  and  other  system  modules  on  one 
parallel  multiplexed  address/data  bus,  the  uNOVA  uses  a two  bus 
architecture.  The  ySOVA  with  a single-chip  CPU  performs  memory 
transfers  over  a parallel  multiplexed  address/data  bus  while  providing 
a second  bus  structure  to  communicate  with  input/output  controllers 
(IOC).  L?  c and  control/address  information  on  the  input/output  bus 
is  transferred  at  an  effective  16.6  MHz  bit  rate.  This  is 
accomplished  via  two  parallel  8.3  MHz  bus  lines  each  with  nine  serial 
time  slots  for  a control  bit  and  data  byte.  Ultimately,  the 
input/output  word  (16-bit)  transfer  rate  is  approximately  920  nsec. 

To  permit  these  high  speed  serial  transfers  in  parallel#  each 
input/output  peripheral  element  must  interface  this  bus  through  a 
special  three-chip  set  available  from  Data  General. 

To  assist  in  minimizing  equipment  costs  and  space  requirements 
MOS  dynamic  RAM  memories  were  chosen.  In  the  LSI-11  system  two 
methods  of  dynamic  RAM  refresh  are  available.  The  CPU  tfu.y  perform  a 
total  memory  refresh  lasting  at  least  130  ysec  and  occuring  every  2.4 
msec.  If  130  ysec  is  too  long  for  a complete  halt  to  all  CPU 
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processing,  a special  bus  module  may  be  added  to  initiate  partial 
refresh  cycles,  each  lasting  2 usee  and  occurring  in  sufficient 
frequency  so  that  all  memory  is  refreshed  within  2.4  msec.  The  uNOVA 
CPU  contains  a hidden  refresh  mechanism  which  automatically  initiates 
partial  refresh  cycles  during  CPU  computations. 

The  LSI-11  utilises  microcoded  CPU  routines  to  perform  the 
basic,  but  very  powerful,  PDP-11  instruction  set.  Conversely,  the 
PNOVA  uses  a more  discreet  step-oriented  instruction  set  which  is 
basic  to  upper  level  Data  General  minicomputers.  To  determine  which 
machine  provides  an  opertional  processsing  advantage,  future 
bench-mark  programming  will  have  to  be  performed  using  routines  for 
the  recommended  design  configuration  which  era  characteristic  of  most 
system  operations. 

According  to  company  representatives,  the  LSI-11  microcomputer 
family  is  available  with  a thirty-to-ninety  day  delay  and  the  yNOVA 
microcomputer  family  will  be  ready  for  quantity  shipping  in  January 
1977^  The  average  estimated  cost  for  a microcomputer-based  network  of 
two,  three  or  four  nodes  is  $89,245.00,  $159,594.00,  and  $228,343.00 
respectively.  These  estimated  costs  include  an  off-line  development 
system  and  are  amplified  in  Section  7 and  detailed  in  Appendix  II. 

4.3  DEVELOPMENT  SYSTEM  OFF-LINE 

One  of  the  most  difficult  aspects  of  implementing  a 
microcomputer-ba3ed  system  is  the  development  and  debugging  of 
resultant  programs.  In  view  of  the  numerous  processing  elements 
identified  by  this  study  in  the  proposed  architecture,  it  was 
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concluded  that  the  following  capabilities  would  be  essential  for  an 
off-line  development  system  for  the  5ENET-DAX.  Figure  4-2  presents  a 
block  diagram  of  the  proposed  configuration. 

a.  Remote  Load  - Loading  the  nodal  processor  "down  line"  by 
the  development  system  upon  generation  of  appropriate 
linked/load  modules 

b.  Multiple  Printers  - Simultaneous  development  of  software 
by  two  or  three  users 

c.  Hi-Speed  Printer  - Ability  to  print  hardcopy  listings 
within  a reasonable  time  period 

d.  Off-line  floppy  disk  storage  (dual) . 

As  configured,  this  system  operating  with  Remote  11,  under  operating 
system  RT-il,  provides  a multi-user  development  capability  capable  of 
producing  managed  assemblies  with  revision  level  capability.  Dual 
floppy  disks  provide  off-line  storage  for  developed  programs  and 
complete  relocatable  load  modules  may  be  "automatically'*  loaded  into 
the  SENET-DAX  nodal  processor  via  Remote-11.  Down-line  loading  of  the 
nodal  processor  is  an  important  capability  due  to  the  number  of 
peripheral-limited  link  processors  which  may  now  be  program  loaded  by 
the  nodal  processor  upon  receipt  of  the  programs  transmitted  to  it 
under  Remote-11.  These  capabilities  and  the  dedicated  purpose  of  this 
off-line  system  will  favorably  and  heavily  influence  the  development 
cycle,  reduce  overall  integration  efforts  and  provide  the  necessary 
development  tools  to  support  the  SENET-DAX  development  effort. 
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Figure  4-2.  Off-line  Software  Development  System 
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SECTION  5 


AN  EXPERIMENTAL  INTEGRATED  VOICE/DATA  SV7XTCHXNG  NETWORK 


5.1  GENERAL 


The  recommended  conceptual  model  will  be  used  to  demonstrate 


the  practicality  of  the  SENET-DAX  concept  in  a realistic  network 


environment.  Figure  5-1  illustrates  three  network  configurations. 


Figure  5-1A  shows  a two-node  network  consisting  of  two  SENET-DAX 


switches  connected  by  a 230.4  kBPS  link*  with  a limited  number  of 


directly  connected  digital  subscribers  at  each  node.  The  two-node 


network  could  support  the  demonstration  of  most  of  the  basic  concepts 


and  services  listed  in  Table  1-1.  In  some  cases,  however,  the 


demonstration  would  be  limited.  For  example,  the  various  levels  of 


packet  switching  protocol  would  be  difficult  to  demonstrate  as  would  a 


realistic  case  of  alternate  routing  of  either  Class  I or  Class  II 


data. 


Figure  5-lB  illustrates  a three-node  fully  connected  network 


with  end  and  tandem  node  capability  and  a limited  number  of  direct 


subscribers.  As  in  the  two-node  network,  the  connecting  links  are 


230.4  kBPS  full-duplex.  This  three-node  network  could  support  the 
demonstration  of  all  the  basic  concepts  and  services  listed  in  Table 


1-1,  in  addition  to  alternate  routing  performed  by  an  originating 


switch  and  spill  backward  routing  at  a tandem  switch.  With  three 


nodes  some  capability  is  given  up,  although  all  of  the  basic  services 


can  still  be  demonstrated. 
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Figure  5-1.  Experimental'  Network  Configurations 


Figure  5-1C  illustrates  a four-node  network  having  two  fully 
connected  nodes  and  two  nodes  each  connected  to  the  remaining  nodes 
but  not  to  each  other.  All  nodes  have  direct  subscribers  and  handle 
trunk-to-trunk  traffic.  This  network  was  described  more  fully  in 
paragraph  1.3.  The  four-node  experimental  network  is  recommended  as 
the  most  suitable  for  exploring  the  concept  for  a working  model  based 
on  the  SENET-DAX  technique.  A four-node  network  allows  demonstration 
of  all  the  fundamental  services  in  Table  1-1,  as  well  as  allowing 
greater  possibilities  for  alternate  routing  and  recovery  from  blocking 
than  in  the  three-node  network.  The  addition  of  more  nodes  (i.e.,  a 
five  or  six-node  network)  would  not  provide  significant  additional 
capability,  except  minimally  with  respect  to  alternate  routing,  and 
would  increase  total  cost  of  the  network.  It  appears  that  the 
four-node  network  is  the  most  effective  in  providing  the  services 
necessary  to  demonstrate  workability  of  the  model. 

Other  advantages  of  the  four-node  configuration  are  that  it 
provides  a multiplicity  of  alternate  routes,  and  will  respond  more 
efficiently  to  local  overload  at  selected  nodes.  Assume  that  a call 
is  made  from  a subscriber  at  switch  A to  a subscriber  at  switch  C.  In 
the  three-node  network  there  is  a primary  path  along  one  link  (A-C) 
and  an  alternate  path  which  transits  two  links  (A-E-C) . With  the 
four-node  network  there  would  be  a choice  of  two  2-link  paths  (A-B-D 
and  A-B-C)  and  two  3-link  paths  (A-B-C-D  and  A-C-B-D) «.  One  could  also 
envision  an  experiment  using  the  traffic  generator  which  could 
simulate  a situation  in  which  displacement  of  subscribers  results  in  a 
temporary  distribution  unbalance  and  concentration  of  subscribers  at 
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particular  nodes.  The  ability  of  the  network  to  adjust  to  this 
situation  could  be  evaluated.  Also,  the  enhances  int  of  survivability 
when  a node  is  lost  could  be  tested  by  the  use  of  diagonal  links. 

Cost  estimates  for  the  two,  three,  and  four-node 
configurations  are  provided  in  Section  7.  If  network  costs  for  the 
four-node  design  preclude  its  use  at  this  stage,  then  the  three-node 
alternative  could  provide  most  of  the  features  that  are  critical  to 
the  evaluation.  The  two-node  network  could  also  demonstrate  that  the 
basic  concept  will  work;  later  on,  two  more  nodes  could  be  added  and 
additional  features  such  as  alternate  routing  could  be  tested.  The 
advantage  of  this  approach  is  that  once  the  software  is  developed  for 
the  two-node  configuration  , most,  if  not  all,  of  the  development  work 
has  been  completed  (this  does  not  include  software  developed  for 
routing).  The  transition  from  a two-node  to  four-node  network  should 
then  take  a relatively  short  time. 

5.2  CAPABILITIES 

The  four-node  network  test  configuration  provides  a means  of 
examining  the  integrated  system  concept  for  an  access  area 
application.  All  of  the  basic  SENET-DAX  conceptual  ideas  in  paragraph 

1.3  and  the  services  in  Table  1-1  car.  be  demonstrated.  The 


establishment  and  maintenance  of  various 
could  demonstrate  system  feasibility  and 
include: 


types  of  call  operations 
flexibility.  Possibilities 


a.  Class  I voice  calls  between  switching  centers,  e.g.,  at 
rates  of  16  kBPS,  2400  kBPS  or  others 


b.  Class  II  interactive  terminal/terminal  and 

computer/terminal  calls  between  switches.  Possibilities  ^ 

for  computer  communication  include  GTE  time  sharing  * 

system,  or  the  ARPANET.  A rudimentary  computer/terminal  ; 

call  can  be  simulated  by  substituting  the  nodal 

processor  for  a teletype  at  one  of  the  switch  locations  | 

c.  Simultaneous  Classl/Class  II  operation  between  switches.  i 

Typical  calls  might  include  a Class  I voice  call  at  16  | 

kBPS,  a Class  I voice  call  at  2400  KBPS  and  a Class  II  J 

interactive  computer/terminal  call.  | 

i 

The  model  will  also  provide  an  investigatory  tool  for  | 

i 

■** 

examining  the  feasibility  of  other  more  advanced  functional  network  ] 

i 

k 

concepts  in  the  future.  These  might  include:  i 


a.  Preemption  of  a Class  I call  by  a Class  II  packet  either  | 

by  the  technique  of  dropping  the  call  or  causing  it  to  J 

be  "interrupted”  for  a frame  in  order  to  transmit  the  J 

packet  I 

| 

b.  Preemption  of  Class  II  data,  e.g.,  a packet,  by  a Class  | 

I call,  with  corresponding  delay  of  the  packet  at  the  J 

node  where  preempted,  or  re-routing  of  the  packet  f 

elsewhere  through  the  network  * 


c.  Mixed  service  for  voice/data  terminals.  This  could 
consider  voice  and  data  multiplexed  and  switched 
together  as  a fixed  increment  in  the  Class  I region  as 
well  as  a hybrid  procedure  which  identifies  the 
particular  service  required  (voice  or  data)  and  connects 
the  corresponding  terminal  to  the  proper  interface 
circuitry 

d.  Dynamic  alternate  routing  with  precedence. 


; I 
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5.3  DEMONSTRATION  DISPLAYS 


Several  displays  could  be  used  to  illustrate  the  basic 
switching  concept  and  implementation  techniques.  Among  these  are 
computer  printouts  and  oscilloscope  waveform  displays.  Printouts  of 
the  channel  map  at  a switching  center  would  illustrate  the  dynamic 
allocation  of  various  channel  widths  to  subscribers  having  different 
terminal  rates,  and  the  drop,  insert,  and  recompacting  of  channels 
during  call  setup  and  release.  Call  setup,  with  its  inherent  forward 
reservations  of  channel  links  during  the  search  phase  and  backward 
allocation  subsequent  to  the  called  party  answering,  would  also  be 
illustrated  effectively  by  printing  out  successive  "snapshots"  of 
network  link  allocation.  Alternate  routing  and  guasi-associative 
routing  can  be  likewise  displayed.  Oscilloscope  waveform  displays  at 
the  trunks  and  subscriber  terminals  with  appropriate  signal  generator 
inputs  applied  to  the  end  terminals  can  be  used  to  dramatize  the 
dynamic  allocation  of  a master  frame  and  the  interaction  between 
channels  of  different  widths.  Specific  patterns  generated  at  a 
subscriber  terminal  may  be  viewed  on  the  trunk,  as  the  Class  I/Class 
II  boundary  dynamically  shifts  in  reaction  to  the  allocation  of  bytes 
appended  to  the  Class  I portion  of  the  frame.  The  positional 
allocation  of  subsequent  calls  and  the  recompacting  of  current  call 
allocations  as  previous  calling  parties  go  on-hook,  can  also  be  shown. 
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SECTION  6 

PERFORMANCE  EVALUATION 


6.1  GENERAL 

In  this  section  the  merits  of  the  distributed  processing  model 
are  examined  as  a function  of  switching  capabilities.  This  included 
the  evaluation  of  cross-network  and  cross-office  delays,  an  assessment 
of  system  capabilities  with  regard  to  traffic  handling,  throughput, 
and  the  amount  of  control  overhead  requiring  transmission  capacity, 
and  an  analysis  of  blocking  and  delays.  Where  applicable,  the 
constraints  and  limitations  on  switching  capability,  as  a result  of 
compromises  necessary  in  order  to  develop  the  experimental  system, 
will  be  assessed. 

6.2  PARAMETRIC  ANALYSIS  OF  TRANSMISSION  EFFICIENCY  AND  THROUGHPUT 
6.2.1  Transmission  Efficiency  and  Throughput  Defined 

Transmission  efficiency  Eff  is  defined  as  the  ratio  of  correct 
information  ITR*  transmitted  over  the  trunk  to  the  trunk  transmission 
rate  R.  The  trunk  transmission  rate  R can  be  further  subdivided  into 
the  sum  of  the  correct  information  exchange  rate  ITR  plus  the 
transmission  rate  of  the  overhead  R0; 


E - ™ - ITR 
ff  R ITR  + Ro 


(6-1) 


* ITR  is  also  known  as  the  throughput  of  the  system. 
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Although  Class  I and  Class  II  data  are  transmitted 
simultaneously  over  the  same  trunk,  ITR  and  Ro  are  different  for  each 
case*  The  overall  transmission  efficiency  is  defined  as  the  weighted 
average  c£  the  Class  I and  II  efficiencies  with  the  weighting  factors 
being  the  percentage  of  each  class  of  traffic  in  the  total  trunk 
traffic.  Thus, 


Ej  ITRj  + Ejj  ITRj-j 
(EI  * EII}  R 


(6-2) 


where  E|  and  Ejj  are  the  Class  I and  Class  II  traffic,  respectively 
and  ITRi  and  ITRn  are  the  respective  Class  I and  Class  II  throughput. 
Note  that  if  Ex  * 0,  no  Class  I traffic  is  transmitted  and  the 
efficiency 

ITEix 


becomes  that  for  Class  II  only.  The  overall  transmission  overhead 
rate  is  thus  given  by 


EI  R°I  * EII  RoIl 
EI  + EII 


(6-3) 


and  the  overall  throughput  by 


IMU  . EI  ITRI  * EII  ITRII 
EI  + EII 


(6-4) 


where 

ITRj  * sffj  ri  is  the  rate  of  correct  information  transmitted 
in  the  Class  I region, 

Rj  is  the  effective  transmission  rate  for  Class  I data, 

ITRji  * Eff i£  Rji  is  the  rate  of  correct  information 
transmitted  in  the  Class  II  region,  and 

Rjl  is  the  effective  transmission  rate  for  Class  II  data. 

In  the  rest  of  this  section  we  will  extend  the  analysis 
undertaken  in  Phase  I and  re-examine  the  characteristics  of 
transmission  overhead  and  throughput  for  Class  I and  II  traffic  in  the 
experimental  network  described  in  this  report.  Then  we  will 
investigate  the  Class  II  efficiency  and  throughput  for  the  lower 
carrier  rate  of  230.4  kBPS,  parametrically,  as  a function  of  packet 
size,  bit  error  rate  and  error  control  protocol. 

6.2.2  Class  I and  II  Traffic  Overhead 

The  portions  of  the  dynamically  allocatable  SENET-DAX  frame 
which  are  considered  to  be  overhead  in  the  experimental  system  will 
now  be  defined.  In  the  Class  I region  CCIS  messages  used  to  establish 
connections  and  dynamically  control  the  position  of  any  channel  within 
the  region  are  considered  to  be  Class  I overhead.  This  includes  the 
messages  used  in  the  establishment  and  termination  of  calls, 
coordination  and  control  of  the  frame,  messages  to  compact  the 
allocation  of  bits  in  the  frame  after  a call  is  terminated,  and  other 
control  messages  which  utilize  the  CCIS  subregion,  such  as  call 
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synchronization  and  resynchronization  messages,  acknowledgments, 
routing  control  and  maintenance  messages*  Other  types  of  overhead 
information  considered  to  be  Class  I overhead  are  the  16-bit 
start-of-frame  markers  for  frame  synchronization,  the  48-bit  frame 
marker  for  resynchronization  and  the  overhead  due  to  bit  stuffing 
because  of  the  8-bit  slot  size.  All  other  data  transmitted  in  the 
Class  I region  will  be  considered  as  effective  throughput  regardless 
of  content  or  transmission  errors.  This  could  include  data  consisting 
of  voice,  noise,  or  idle  periods,  or  facsimile  with  forward  error 
control  (FEC) . 

During  the  Phase  I study  it  was  found  that  CCIS  messages,  the 
SOF  marker  signifying  the  start-of-frarae,  and  bit  stuffing  because  of 
the  8-bit  slot  size,  were  a small  fraction  of  the  total  overhead  (on 
the  order  of  1 percent) . This  was  examined  for  the  case  of  a T1 
carrier  rate  (1.544  MBPS)  and  a 10  msec  frame.  A switch  capable  of 
serving  a maximum  of  300  voice  subscribers  at  a 0.1  percent 
grade-of-service  and  372  data  subscribers  was  derived  from  these 
system  parameters.  Here  we  consider  an  experimental  model  which 
utilizes  a lower  trunk  transmission  rate  (230.4  kBPS);  however,  it 
only  has  the  capability  of  serving  a maximum  of  20  voice  subscribers 
and  360  data  subscribers  at  the  same  grade-of-service  requirements. 
Therefore,  we  expect  the  percentage  of  Class  I overhead  to  remain  a 
small  proportion  of  the  tot2l.  For  this  reason  further  examination  of 
Class  I overhead  was  curtailed  and  attention  directed  to  the  Class  II 
region  where  the  effect  of  using  a lower  transmission  rate  was 
evaluated  for  Class  II  throughput  and  efficiency. 
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Class  II  overhead  consists  of  several  major  categories.  One 
category  concerns  the  non-information  bits  of  a packet,  such  as  those 
bits  in  the  flag,  address,  control  or  frame  check  sequence  fields, 
that  are  transmitted  over  the  trunk  along  with  bits  of  the  information 
field.  These  provide  a means  of  exchanging  data  between  nodes  in  a 
network  and  include  the  functions  of  message,  packet  and  network  error 
control,  sequencing,  supervisory  control,  addressing,  and  additional 
link  control  functions.  The  retransmission  of  packets  which  are 
delivered  in  error  is  also  catagorized  as  overhead. 

A third  category  concerns  the  idle  time  spent  by  the  trunk 
while  waiting  for  an  acknowledgment  (ACK)  that  the  packet  just 
transmitted  has  been  received  correctly,  as  is  the  case  of 
block-by-block  ARQ.  For  continuous  ARQ-Type  I,  where  all  packets 
transmitted  in  the  intervening  time  between  the  transmittal  of  the 
erroneous  packet  and  receipt  of  the  negative  acknowledgment  (NACK)  are 
retransmitted,  this  overhead  consists  of  the  time  necessary  for 
retransmitting  the  correct  packets. 

Class  II  transmission  efficiency  and  throughput  are  a function 
of  the  error  environment,  packet  size  and  structure,  ARQ  error 
protocol,  and  the  transmission  rate  of  the  system.  During  Phase  I, 
equations  for  transmission  efficiency  were  derived  and  analysed  to 
determine  an  optimum  packet  size  that  maximized  the  efficiency  for  a 
given  error  environment.  The  results  demonstrated  that  transmission 
efficiency  increases  with  improved  error  environment  and  exhibits  a 
resonance  phenomenon  for  variations  in  packet  size,  with  the  optimal 
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packet  size  fee  greatest  efficiency  increasing  at  roughly  one-third 
the  rate  of  improvement  in  the  error  environment.  In  this  report  we 
examine  these  results  for  the  lower  transmission  rate  of  230.4  kBPS 
and  extend  the  analysis  to  include  the  Class  II  throughput. 


6.2.3  Optimization  of  Class  II  Transmission  Efficiency  (Eff)  and 
Throughput  (ITR)* 


The  parameters  which  are  used  in  the  derivation  of  the 

transmission  equations  are  listed  below.  These  includes- 

* 


Eg  « Probability  of  a bit  being  incorrect 

DC  * Duty  cycle  of  noise  burst,  i.e.,  percentage  of 

time  during  which  a burst  condition  exists 

P « Packet  size,  composed  of  I information  bits  and  C 

control  bits  {includes  bits  from  the  flag,  address 
and  control  fields,  frame  check  seguence  and/or 
parity  bits,  sequence  numbers,  stuffing  bits  for 
filling  out  words  or  blocks,  and  packet  length  or 
I.D.  features) 


Ru  * Class  II  trunk  transmission  rate 

T = Time  spent  in  transmitting  a packet 

W * Time  spent  waiting  for  a transmitted  packet  to  be 

acknowledged. 


*For  convenience  of  notation,  in  the  rest  of  the  report,  Eff  and  ITR 
will  be  taken  to  be  the  Class  II  transmission  efficiency  and 
throughput,  respectively. 
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Error  control  is  an  ARQ  form  of  protocol  whereby  the  receiving 
link  processor  monitors  the  incoming  signal  for  transmission  errors 
and  notifies  the  transmitting  processor  when  it  is  necessary  to  repeat 
the  packet.  The  transmitter  is  notified  via  a control  message  over 
the  return  link.  Three  types  of  ARQ  error  control  were  considered: 
block-by-block  ARQ  and  two  types  of  continuous  ARQ,  In  block-by-block 
ARQ,  after  transferring  a block,  the  trunk  remains  idle  while  waiting 
for  the  acknowledgment  in  order  to  transmit  the  next  block  of 
information.  In  continuous  types  of  ARQ  systems,  there  is  no  waiting 
time  for  acknowledgment  after  a packet  is  sent.  As  soon  as  a packet 
is  transmitted  the  next  one  is  sent.  When  a NACK  is  received  for  a 
particular  packet,  either  all  packets  transmitted  in  the  intervening 
time  between  the  original  transmission  of  the  erroneous  packet  and  the 
receipt  of  the  HACK  are  retransmitted  (ARQ-Type  I)  or  only  the 
erroneous  packet  in  question  need  be  transmitted  (ARQ-Tvpe  II).  The 
latter  case,  where  only  the  packet  that  was  detected  in  error  is 
repeated,  produces  more  efficient  operation  than  either  of  the  other 
two  ARQ  schemes. 


Class  II  information  is  transmitted  across  the  trunk  in 
packets  of  P bits  each.  The  ratio  of  non-overhead  bits  to  the  total 
packet  size  is  given  by  ^ where  P = I+C.  Sometimes  a bit  is  in  error, 
causing  the  packet  to  be  in  error.  This  causes  the  efficiency  to  be 
modified  according  to 

I 

[P/  (1-Ep)  3 ' 
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where 


EP  « 1-(1-EB)P. 


Ep  is  the  probability  of  a bit  being  incorrect,  (1-EB)P  is  the 
probability  of  a packet  being  correct,  and  Ep  is  the  probability  of  a 
packet  being  in  error  in  a random  error  environment.  For  small  values 
of  Ep 

P -PE 

1 - Ep  = U-ERr  * e 


JB. 


If  the  channel  is  subjected  to  error  bursts,  the  effect  during  the 
time  of  the  burst  is  to  render  the  channel  useless.  The  channel  is 
less  efficient  in  proportion  to  the  time  the  burst  condition  exists, 
i.e.,  I 


(F/(1-Ep)  U-DCJ  J* 

The  effect  of  a noise  burst  will  be  to  delay  the  transfer  of 
information  while  waiting  for  acknowledgments.  In  block-by-block  ARQ 
the  transmitter  is  idle  from  the  time  it  sends  the  last  bit  of  a 
packet  until  it  receives  and  interprets  the  return  ACK  or  HACK 
message.  The  efficiency  becomes 


(P/(1-Ep) (1-DC) 3 T+W  ' 


wnere 


m = P/U-DC). 
1 R 


is  the  time  it  takes  to  transmit  one  packet  during  the  time  that  the 
channel  is  usable  and  W is  the  waiting  time  per  packet.  Taking  all 
this  into  account,  the  transmission  efficiency  for  block-by-block  ARQ 
is  given  by  the  expression 


■ a.—.. 
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ff  I + C + WR 
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The  throughput  is  this  efficiency  multiplied  by  the  channel  Class  IX 


transmission  rate,  i.e.. 


RIZ  IE  " (1  - DC) 

ITR  = Eff  RIZ  = i ^ c+  WRZI  (i  -DC) 


(6-6) 


By  differentiating  equation  (6-5)  with  respect  to  the  packet  size  and 
setting  the  result  equal  to  zero,  dEP.. 


the  optimum  packet  size  can  be  determined  and  is  given  by  the  solution 


of  the  equation 


+ [c  + mIZ  (1  - DC)]  I - 


[C  + WRtt  (1  - DC)] 


= 0 (6-7) 


Solving  for  I we  find 


(C  + WR  (1  - DC)] 


In  the  continuous  ARQ-Type  I mode  where  all  data  following  the 
packet  in  error,  is  retransmitted,  a waiting  period  is  suffered  c !y 
when  an  error  occurs.  The  efficiency  thus  becomes 


T+W(l-e”FEB) 


‘ $:<•  <?, . t-i  i^’  iJPr'Sf.gJ 


represents  the  non-productive  time  during  which  the  channel  is  idle 
because  the  packet  is  in  error  and  data  must  be  resent.  In  this  case 


the  transmission  efficiency  is  given  by 


(1  - DC) 


I + C + WRI];  (1-DC)  ( 1 - e °) 


(6-10) 


and  the  throughput  by 


ITR  = 


Rn  Ie 


(1  - DC) 


(6-11) 


I + C + WRjj  (1  - DC)  (1  - e ) 


These  parameters  are  maximized  by  differentiating  with  respect  to  I 


a.id  equating  to  zero.  Iopt  is  then  the  solution  of  the  expression 


v2  + Cc  + WRjj  (1  - DC)]ebI  - [c  + WRI3;  (1  - DC)]  + 


WRjj  (1  - DC) e 


(6-12) 


which  may  be  solved  by  the  method  of  successive  approximations  [2]. 
Results  of  this  are  shown  in  paragraph  6.2.4. 

For  the  continuous  ARQ-Type  II  mode,  where  only  the  packet  in 
error  is  retransmitted,  the  efficiency  is  modified  according  to  the 


expression 


I T 

[P/ (1-Ep) (1-DC) ]*  T+P(1.e-PEB) 

R 


where 


| (l-e-pEB) 


represents  the  non-productive  time  spent  in  transmitting  a packet 

which  is  in  error  and  therefore  must  be  considered  to  be  pure 

overhead.  The  transmission  efficiency  thus  becomes 

-PE„ 


_ Ie 


(1  - DC) 


(6-13) 


I + C t P (1  - DC)  (1  - e 
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and  the  throughput 


ITR  = 


-PE 


RII  I£ 


B 


(1  - DC) 


-PE 


B\ 


I + C + P (1  - DC)  (1  - e ) 

The  method  of  solution  is  the  same  as  before  and  leads  to  the 
following  expression 

2 “PEn 

(2-DC)  EbI  + (2-DC)  Cl  - (2-DC)  C + (1-DC)  Ce  B = 0 


(6-14) 


(6-15) 


which  also  may  be  solved  by  successive  approximation  [2],  the  results 
of  which  will  be  shown  in  paragraph  6.2.4 


6.2.4  Variation  of  Ef f and  ITR  with  Packet  Size  and  Bit  Error  Rate 

Using  typical  SENET-DAX  baseline  parameters,  a study  of  the 
variation  of  transmission  efficiency,  throughput,  optimized  packet 
size,  and  other  performance  parameters  was  conducted  for  varying 
values  of  bit  error  rate  for  block-by-block  ARQ  and  the  two  types  of 
continuous  ARQ.  The  maximum  Class  II  transmission  rate  was  44.8  kBPS, 
which  corresponded  to  approximately  20  percent  of  the  trunk  capacity 
of  the  230.4  kBPS  carrier  used  in  the  experimental  system.  The 
results  are  shown  in  Figures  6-1  through  6-6  and  in  Table  6-1. 
Continuous  ARQ  provides  a greater  efficiency  (throughput)  than 
block-by-block  ARQ,  but  requires  greater  data  capacity.  Continuous 
ARQ-Type  II,  where  only  the  erroneous  packet  is  repeated,  produces  the 
greatest  improvement  in  efficiency  (throughput)  for  the  error 
environments  investigated.  For  a constant  packet  length,  efficiency 
(throughput)  improves  as  Bit  Error  Rate  (BER)  improves  (see  Figures 
6-1,  6-2,  and  6-3).  At  low  BER*s  (10-7),  the  larger  the  packet  size, 
the  better  the  transmission  efficiency,  while  at  high  BER’s  (10~3) 
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Figure  6-2.  Transmission  Efficiency  vs.  Bit  Error  Rate 
Continuous  ARQ-Type  I 


Figure  6-3.  Transmission  Efficiency  vs.  Bit  Error  Rate 
Continuous  ARQ-Type  II 


Figure  6-4.  Transmission  Efficiency  vs.  Packet  Size  Block-by-Block  arq 


Figure  6~6.  Transmission  Efficiency  vs.  Packet  Size 
Continuous  ARQ-Type  II 
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just  the  opposite  occurs;  the  larger  packets  have  poorer  efficiency 
(throughput)  ratings.  The  reasons  for  this  are  obvious.  As  more  bits 
are  transmitted  per  packet,  the  transfer  becomes  more  efficient.  At 
high  BER's,  a considerable  number  of  errors  occur,  causing 
retransmission  of  erroneous  packets.  All  packets  with  errors  in  them 
are  considered  to  be  pure  overhead.  Therefore,  the  more  bits 
transmitted  per  packet,  the  less  likely  it  is  of  reaching  its 
destination  in  a bad  error  environment,  hence  the  more  inefficient  the 
transfer.  Likewise,  the  smaller  the  packet  size,  the  more  likelihood 
there  is  of  it  being  received  without  error. 

For  a constant  error  environment,  as  the  packet  length  is 
increased,  an  optimal  efficiency  (throughput)  is  reached  (see  Figure 
6-4,  6-5,  and  6-6).  Increasing  the  packet  size  beyond  this  value 
results  in  a decrease  in  efficiency  (throughput)  for  the  reasons  noted 
above.  Thus  a resonance  effect  is  observe.,.  This  optimum  occurs  at  a 
different  packet  size  for  different  BER's.  As  the  error  environment 
becomes  more  error-free,  the  maximum  transmission  efficiency 
(throughput)  that  the  system  can  attain  increases  and  the  larger  the 
optimum  packet  size  becomes.  At  high  bit  error  rates  it  is  more 
efficient  to  transfer  small-sized  packets;  however,  the  maximum 
efficiency  (throughput)  obtainable  is  somewhat  limited.  At  low  BER's 
it  is  more  efficient  to  transmit  larger  packets.  As  the  BER 
decreases,  the  maximum  transmission  efficiency  (throughput)  obtainable 
approaches  unity  in  the  limit. 
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The  same  information  can  be  displayed  in  tabular  form  (see 
Table  6-1).  A packet  is  composed  of  information  bits  (I)  and  control 
bits  (C) . Equations  (6-8),  (6-12),  and  (6-15)  are  solved  for  l0pt» 
the  optimum  packet  size,  and  substituted  into  equations  (6-5) , (6-6) , 
(6-10) , (6-11) , (6-13) , and  (6-14)  to  obtain  Eff0pt»  the  optimum 
transmission  efficiency,  and  ITR*^,  the  optimum  throughput,  for  a 
given  BER.  As  the  error  environment  improves,  the  optimum  packet  size 
becomes  larger  and  the  transmission  efficiency  approaches  unity. 
Likewise,  the  Class  II  throughput  approaches  its  maximum  of  44.8  kEPS. 
Por  continuous  ARQ-Type  II,  at  a BER  of  10-3,  the  optimum  packet  size 
is  224  bits,  the  transmission  efficiency  is  46,7  percent  and  the 
throughput  is  20.92  kBPS  (see  Table  6-1).  This  is  3 times  better  than 
block-by-block  ARQ  and  1.7  times  better  than  continuous  ARQ-Type  I. 

The  probability  of  a packet  being  received  in  error  is  20.07  percent. 

6.2.5  Data  Utilization  as  a Function  of  Voice  Traffic 

Figure  6-7  shows  the  allocation  of  bits  in  a frame  for  several 
packet  sizes  with  continuous  ARQ  protocol.  Type  II,  i.e.,  repeating 
all  data  from  a HACK.  In  paragraph  6-3  it  will  be  shown  that  for  a 
packet  size  of  224  bits  (optimum  for  a lO^  BER) , a busy  hour  data 
load  of  200  packets  per  second  (or  2 packets/frame)  can  be 
accommodated  along  with  an  offered  voice  traffic  load  of  4 erlangs, 
with  negligible  queuing  delay  (less  than  .1  msec  per  packet)  due  to 
traffic  congestion.  With  this  arrangement  (Figure  6-7a)  a 
grade-of-service  of  .1  percent  can  be  guaranteed  for  the  4 erlangs  of 
voice  traffic,  and  one  CCIS  message  (maximum  number  of  bits  * 232)  can 
be  carried  simultaneously  with  the  voice  and  data.  The  efficiency 
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attained  with  an  optimum  packet  size  of  224  bits  is  *467  while  that 
attained  with  a packet  size  of  600  bits  is  .763.  It  is  interesting  to 
note  from  Figure  6-6  that  the  efficiency  for  the  sub-optimum  packet 

size  of  1024  bits  (which  is  the  maximum  packet  length  for  the  ARPA 

«• 

Network)  is  equal  to  .735.  Therefore,  even  though  an  optimum  packet 
size  can  be  specified,  efficiencies  do  not  vary  significantly  over  a 
wide  range  of  packet  sizes  since  the  curves  are  relatively  flat  for 
most  of  the  error  rates  in  Figure  6-6. 

Table  6-2  shows  the  variation  of  the  link  data  capacity  as  a 
function  of  the  voice  traffic  laod  for  the  optimum  packet  size  of  224 
bits  (Figure  6-7a) . For  the  busy  hour  data  load  of  2 packets  per 
frame  and  an  offered  traffic  load  of  4 erlangs,  the  percentage  of  the 
frame  available  for  packet  data  transmission  is  61.89  percent.  This 
falls  to  28.9  percent  when  overhead  due  to  noise  is  taken  into 
account.  The  data  utilization  factor,  which  represents  how  much  of 
the  realizable  throughput  is  used  for  transmission  of  the  busy  hour 
data  load,  is  67.28  percent.  This  corresponds  to  a total  trunk 
utilization  of  79.77  percent.  It  can  be  seen  from  Table  6-1  that  a 
maximum  of  7 erlangs  of  voice  can  be  tolerated  and  still  retain  the 
capacity  to  carry  the  busy  hour  data  load.  The  peak  trunk  utilization 
factor  then  is  99.84  percent  of  the  link  data  capacity  during  the  busy 
hour,  or  99,74  percent  of  the  total  trunk  capacity.  Decreasing  the 
peak  data  load,  e.g.»  to  a rate  of  100  packets/sec,  would  allow  more 
voice  traffic  to  be  tarried. 
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TABLE  6-2.  DATA  UTILIZATION  AS  A FUNCTION 
OF  OFFERED  VOICE  TRAFFIC 


This  type  of  chart  illustrates  the  upper  bound  on  voice  and 
data  packets  carried  simultaneously  and  provides  a means  for  analyzing 
how  one  type  of  traffic  can  be  increased  at  the  expense  of  the  other* 
For  a constant  packet  size,  as  the  bit  error  rate  decreases,  the  more 
efficient  the  transfer  of  information,  and  the  lower  the  peak  trunk 
data  utilization  (the  trunk  is  used  less  for  retransmission  of 
incorrect  packets).  However,  as  the  packet  size  is  increased,  the 
upper  limit  on  voice  traffic  carried  is  realized  sooner.  For  example, 
at  a bit  error  rate  of  10~4f  an  optimum  packet  size  of  600  bits  is 
specified.  Taking  into  account  the  effects  of  noise,  the  busy  hour 
data  load  of  2 packets  per  frame  and  4 erlangs  of  voice  would  result 
in  an  overload  condition.  However,  we  could  transmit  one  packet  per 
frame  and  4 erlangs  of  voice  simultaneously  with  a data  utilization 
factor  of  55.15  percent  and  a total  trunk  utilization  of  72.24 
percent. 

6.2.6  Throughput  and  Efficiency  as  a Function  of  Transmission  Rate 

Several  interesting  points  come  to  light  when  we  compare  the 
results  on  transmission  efficiency  and  throughput  with  those 
determined  during  the  Phase  I study.  For  block-by-block  ARQ  and 
continuous  ARQ-Type  I,  the  transmission  efficiency  (see  equations 
(6-5)  and  (6-10))  varies  inversely  with  Rn,  the  Class  II  transmission 
rate.  Therefore,  all  else  being  equal,  we  would  expect  the 
efficiencies  for  the  model  to  be  greater  than  that  obtained  in  Phase  I 
since  we  employ  a lower  carrier  rate  (230.4  RBPS  versus  1.544  MBPS  in 
Phase  I) . This  can  be  seen  from  the  curves  and  from  the  chart  of 
optimal  efficiencies  in  Table  6-1,  Specifically  for  a 10“3  BER,  the 
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optimum  efficiency  for  block-by-block  ARQ  is  ,1617  and  for  continuous 
ARQ,  Type  I it  is  .2744.  ^ Phase  I these  quantities  were  .0335  and 

.0658,  respectively.  The  efficiency  for  continuous  ARQ-Type  II  is  not 
a function  of  Class  II  transmission  rate  and  thus  will  not  change  as 
the  carrier  rate  is  varied.  Therefore,  the  curves  in  Figures  6-3  and 
6-6  are  identical  to  those  derived  during  Phase  I. 

Class  II  throughput  is  just  the  transmission  efficiency 
multiplied  by  the  transmission  rate  of  Class  II  data.  The 
transmission  rate  is  about  20  percent  of  the  230.4  kBPS  carrier  rate, 
or  44.8  kBPS.  This  is  consistent  with  Phase  I (where  308,800  kBPS  was 
the  nominal  data  rate,  or  20  percent  of  1.544  MBPS  rate)  and  allows 
for  busy  hour  date  transmission  of  two  packets  per  frame,  each  224 
bits  in  length.  The  throughput,  plotted  with  transmission  efficiency 
along  the  vertical  axis  in  Figures  6-1  through  6-6,  varies  from  zero 
to  a maximum  of  44.8  kBPS,  about  one-seventh  the  maximum  Class  II 
throughput  considered  in  Phase  I.  For  example,  the  maximum  throughput 
at  a x0"3  bit  error  rate  for  block-by-block  ARQ,  continuous  ARQ-Type  I 
and  continuous  ARQ  Type-II  is  7.24  kBPS,  12.29  kBPS,  and  20.92  kBPS, 
respectively  (see  Table  6-1) . In  Phase  I the  corresponding  values  of 
throughput  were  10.34  kBPS,  20.32  kBPS,  and  144,21  kBPS. 

Table  6-3  summarizes  the  Class  II  throughput  and  its  slope  for 
the  three  types  of  ARQ  protocol.  In  Figure  6-8  and  6-9  these  are 
plotted  as  a function  of  the  transmission  rate  for  the  case  where  Eq  = 
1Q~3  an(j  p0pt  “ 224  bits.  As  the  transmission  rate  increases,  the 
curves  for  block-by-block  and  continuous  ARQ-Type  I level  off 
approaching  values  of  4.369  kBPS  and  21.766  kBPS  respectively,  in  the 
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limit  (see  Table  6-3  and  Figure  6-8).  The  throughput  associated  with 
continuous  ARQ-Type  II/  however#  keeps  increasing  in  a manner 
proportional  to  the  increase  in  transmission  rate.  At  very  high 
transmission  rates  repeating  only  the  information  in  error  is  a highly 
efficient  way  of  transmitting  data  and  leads  to  high  throughput 
capability*.  Transmission  capacity  is  not  being  wasted  by  waiting  for 
data  to  be  acknowledged  before  sending  the  next  block  or  by  repeating 
data  that  was  sent  correctly  the  first  time.  Our  operating  point  for 
this  investigation  is  at  44.8  kBPS.  Here  the  advantage  of  continuous 
ARQ-Type  II  is  not  as  pronounced  as  was  the  case  of  308.8  kBPS#  the 
operating  point  for  Phase  I.  Notice  that  at  extremely  low 
transmission  rates  the  advantage  appears  to  shift  away  from  Type  I ARQ 
to  the  other  protocols.  However,  this  is  a complicated  function  of 
the  Class  II  transmission  rate,  the  packet  length  specified,  and  the 
waiting  time  W and  will  vary  considerably  depending  upon  the  values 
assumed  for  these  parameters. 

In  Figure  6-9  the  slope  of  the  throughput  at  high  transmission 
rates  for  block-by-block  ARQ  and  continuous  ARQ-Type  I is  inversely 
proportional  to  the  square  of  the  transmission  rate.  For  continuous 
ARQ-Type  II,  this  slope  is  a constant  function  of  transmission  rate. 

For  the  experimental  system,  continuous  ARQ-Type  II  protocol 
appears  to  have  the  best  characteristics  of  throughput  and  efficiency 
for  our  transmission  rates  of  interest.  This  will  be  further  examined 
in  the  next  section. 


* It"  is  assumed  that  a sufficiently  fast  processing  capab: 
available  to  accomplish  the  required  data  transfer. 
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6.3  ANALYSIS  OF  BLOCKING  AND  DELAYS 


6.3.1  Blocking  Probability  fog  Voice  Calls  and  Expected  Delay  for 
Data  Messages 


Traditional  parameters  of:  performance  for  voice  and  data 
systems  are  the  blocking  probability  for  voice  calls  and  the  expected 
waiting  time  for  data  delivery,  itaalytical  methods  for  computing 
these  measures  are  well  documented  for  voice  and  data  systems  taken 
individually.  Here  we  are  concerned  with  computational  procedures  for 
composite  voice/data  systems  (in  which  interaction  between  the  voice 
and  data  boundary  is  dynamically  adjustable)  and  varies  as  a function 
of  traffic  demand  by  class. 


It  is  necessary  that  computational  procedures  employed  at  this 
design  stage  of  the  investigation  allow  calculations  to  be  made 
rapidly,  yet  provide  sufficient  accuracy  for  describing  the 
performance  characteristics  of  the  model.  Exact  analytical  solutions 
for  system  performance  exist,  [9]?  however,  they  engender  considerable 
computational  complexity.  For  example,  determining  the  blocking 
probability  for  voice  calls  requires  the  solution  of  a large  system  of 
linear  equations  while  the  waiting  time  for  data  requires  the 
derivation  of  complex  roots.  Although  the  techniques  are  very 
accurate,  the  need  for  such  powerful  computational  schemes,  which 
require  a large  computer  for  implementation,  is  questionable  for  this 
immediate  application.. 
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During  the  Phase  I literature  reviow,  various  approximations 
to  calculation  of  these  performance  measures  were  derived  [9,13,21]. 
For  blocking  probability  of  voice  or  virtual  circuit  switched  traffic 
(Class  I) , the  erlang  loss  formula  was  used,  while  for  the  expected 
waiting  time,  an  approximation  was  suggested  based  on  substituting  the 
M/M/N  queueing  model  for  the  more  complicated  M/D/N  system.  A review 
of  the  derivations  of  these  formulae  with  respect  to  our  application 
and  some  preliminary  calculations,  showed  that  the  approximations 
introduce  errors  which  are  small  compared  with  the  10  msec  frame 
interval.  The  erlang  loss  formula,  given  by 
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is  the  traditional  method  used  to  calculate  blocking  probability  and 
is  justified  when  the  expected  number  of  voice  arrivals  (Xb)  is  small. 
Ej  is  the  Class  I traffic  offered  to  the  trunk  and  equals  A/y  erlangs, 
where  A is  the  call  origination  rate,l/p  is  the  holding  time  per  call, 
b c 10  msec  is  the  service  time  of  the  system,  and  S is  the  finite 
number  of  voice  channels  available. 

An  exact  solution  for  the  expected  delay  involves  the  M/D/N 
queueing  model,  which  specifies  Poisson  arrivals  and  a constant 
service  time.  However,  these  conditions  yield  extremely  complex 
equations  whose  solution  becomes  tractable  only  by  using  a large 
computer.  Therefore,  the  M/M/N  model,  which  specifies  Poisson 
arrivals  and  exponentially  distributed  service  times,  was  substituted 
for  the  more  exact  M/D/N  model  to  reduce  the  complexity  of  the 
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calculations.  The  M/M/N  approximation  yields  a larger  average  waiting 
time  than  the  M/D/N  model  and  therefore,  errors,  introduced  by  the 
approximation,  are  such  as  to  produce  conservative  results. 


In  the  expression  for  delay,  EW  is  given  by 
b Nb.E(N,p2) 

ew  * b + % + {n»p2>  [n  - p2  + p2  eTnTp^TT 


(6-17) 


where  is  the  average  waiting  time  to  get  into  the  queue  to  be 
serviced, 

NbE  (K,p2) 

(n-p2)  in  - P2  + P2E  (n,p2)] 

is  the  time  spent  waiting  in  the 
queue,  and  b is  the  service  time  once  entry  into  the  system  is 
achieved.  N is  the  maximum  amount  of  data  allowed  in  the  system, 
while  P 2 represents  the  offered  data  load.  Both  the  M/H/N  and  M/D/N 
models  are  examples  of  imbedded  Markon  chains,  where,  at  entry  points 
denoted  by  the  fixed  time  interval  b,  the  system  services 
entries  waiting  in  the  queue. 


Equations  (6-16)  and  (6-17)  compute  the  "steady  state*  values 
of  the  blocking  probability  and  the  expected  delay  time.  In  practical 
networks,  however,  the  traffic  may  vary  from  very  small  trunk 
utilization  to  periods  of  time  during  which  the  traffic  load  exceeds 
the  available  trunk  capacity.  During  these  periods  of  overload,  the 
queue  size  and  delay  of  data  packets  can  grow  without  limit,  since 
Class  IT  data  is  not  blocked,  but  only  delayed.  If  an  overload 
condition  were  to  last  a time  approaching  infinity,  the  queues  and  the 
queueing  delays  would  also  grow  towards  infinity.  Our  steady  state 


solutions  disregard  this  overload  effect  and  as  a result  queue  size 
and  average  waiting  time  may  be  underestimated  by  not  taking  into 
account  the  time  spent  in  the  queue  during  overload.  Kumroerle  111] 
suggested  a correction  term  based  on  calculating  approximately  the 
momentary  mean  queueing  delays  corresponding  to  each  overload  state 
and  using  the  respective  probabilities  of  these  states  in  a weighted 
sum  of  the  delays.  The  corrective  terra  was  then  added  to  the  steady 
state  values  of  expected  delay  in  order  to  account  for  this  overload 
phenomenon.  Rummer le*s  results#  however#  even  with  the  corrective 
term#  show  the  delay  and  queue  sizes  to  be  underestimated  by  factors 
as  high  as  2 to  1 when  the  data  traffic  load  exceeds  the  trunk 
capacity  exclusively  reserved  for  data.  Therefore,  until  we  are  in  a 
position  to  more  accurately  determine  the  peak  queue  distributions 
that  would  develop  in  an  experimental  SENET-DAX  network#  we  will 
continue  to  use  the  steady  state  estimates  of  delays  and  queue  size 
that  were  developed  in  the  Phase  I study.  We  must  be  careful# 
however#  to  recognize  that  calculations  of  waiting  time  ;>r  queue 
length  are  only  approximate#  particularly  for  high  traffic 
utilization. 

6.3.2  Variation  of  Waiting  Time  and  Trunk  Utilization  with  Traffic 
Load 

The  3teady~stato  approach  described  above  was  modified  to 
handle  movable  domain  boundaries  and  variable  length  channels  for 
voice  and  data  packets.  With  these  computational  tools  then  defined# 
a parametric  analysis  of  delay  versus  data  service  was  performed  for 
the  experimental  system.  An  analysis  was  made  of  a 230.4  kBPS  trunk 
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used  to  carry  a Class  I voice  load  of  4 erlangs  and  a parametric  data 
load  varying  from  1 to  6 data  packets#  each  224  bits  in  length*  The 
voice  load  was  chosen  to  approximate  the  typical  peak-hour  voice 
traffic  expected  on  an  interswitch  trunk  of  the  experimental  network. 
Expected  holding  time  per  call  was  5 minutes.  A frame  intirval  of  10 
msec  was  assumed. 


The  2304  bits  of  the  230.4  kBPS  trunk  were  allocated  to  voice 
channels,  each  155  bits  in  length,  data  packets  of  224  bits  each,  one 

232-bit  CCIS  message,  a 16-bit  SOF  marker,  and  10  bits  set  aside  for 

* 

bit  stuffing  (via  ADCCF  protocol) . The  155  bits  per  voice  channel 
were  obtained  from  an  average  distribution  of  voice  terminals  served 
by  the  SENET-DAX  model  and  is  based  on  1985  DOD  projected  statistics. 
Each  voice  user  is  allocated  a normalized  155-bit  voice  channel;  thus, 
4 erlangs  of  voice  occupies  4 channels,  or  620  bits.  Packet-switched 
data  traffic  occupies  the  remaining  Class  I/Class  II  space  not  used  by 
voice.  One  232-bit  channel  was  reserved  for  CCIS  traffic  for 
establishing  and  breaking  down  calls,  and  for  dynamic  control  of  trunk 
allocation. 

Waiting  time  delays  and  trunk  utilization  factors  were 
computed  for  both  fixed  and  flexible  Class  2/Class  II  boundaries  (see 
Table  6-4) » Probability  of  loss  (voice  call  blocking  probability)  was 
considered  independent  of  data  traffic  (priority  is  not  considered 
here) . Four  erlangs  of  voice  traffic  offered  to  about  80  percent  of 
the  total  frame  interval  produced  a probability  of  lost  calls  due  to 
trunk  blockage  of  .001  (0.1  percent).  However,  any  unused  voice 
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TABLE  6-4 . VARIATION  OF  THE  WAITING  TIME  AND  DATA  UTILIZATION  WITH 

OFFERED  DATA  TRAFFIC  FOR  FIXED  AND  MOVABLE  BOUNDARY  CASES 
230.4  KBPS  TRANSMISSION  RATE 
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channels  can  be  used  for  packet-switched  data.  The  voice  utilization 
is  34  percent  assuming  an  offered  load  of  4 erlangs  and  taking  into 
account  calls  which  are  blocked. 

The  data  load  was  varied  parametrically  from  1 to  6 packets. 
Waiting  time  consists  mainly  of  the  fixed  component  (15  msec),  which 
represents  the  time  spent  waiting  to  enter  the  system  (on  the  average 
one-half  of  the  frame  interval) , and  the  service  time  (equal  to  the 
frame  period).  An  additional  delay  is  present  due  to  expected  waiting 
time  in  the  input  queue  and  is  variable.  Trunk  utilization  is  much 
better  for  the  flexible  boundary  case,  where  data  is  allowed  to  make 
use  of  all  available  frame  capacity,  than  for  the  fixed  boundary  case 
where  data  is  restricted  to  one  packet  each  frame.  For  the  flexible 
boundary  case,  as  data  load  is  increased,  expected  waiting  time  is 
relatively  constant,  up  to  about  5 packets  (30  percent  of  the 
available  data  capacity)*  After  this,  waiting  time  increases  rapidly. 
Up  until  this  point,  delay  consists  mainly  of  the  fixed  component 
(1.5)  multiplied  by  the  service  time.  Excessive  queueing  delay  comes 
in  above  the  80  percent  data  utilization. 


For  the  flexible  boundary  case,  4 erlangs  of  voice  traffic,  at 
a grade-of-service  of  .1  percent  can  be  accommodated  along  with  2 data 
packets  with  insignificant  delay  (less  than  .1  msec),  on  a single 
230.4  kSPS  link.  This  represents  a data  utilization  of  31.5  percent 
and  an  overall  trunk  utilization  of  57.6  percent.  Alternatively  5 
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packets  pet  frame  can  be  accommodated  with  20.8  msec  delay.  A 
corresponding  tradeoff  analysis  cannot  be  made  for  the  fixed  boundary 
case,  since  no  more  than  1 packet  per  frame  can  ever  be  sent  on  the 
link. 


Table  6-5  shows  the  same  information  for  a trunk  rate  of  1.544 
MBPS  (T1  carrier)  with  normalized  voice  channels  and  224-bit  data 
packets  as  proposed  for  the  experimental  system.  At  this  transmission 
rate,  for  the  moving  boundary  case,  63.5  erlangs  of  yoice  traffic  can 
be  carried  at  a .1  percent  grade-of-service  along  with  15  data  packets 
with  negligible  delay.  This  represents  a data  utilization  of  63.5 
percent  and  an  overall  trunk  utilization  of  87.4  percent.  Up  to  20 
packets  can  be  carried  each  frame  with  16.2  msec  delay.  Comparison  of 
these  results  with  those  in  Table  6-4  shows  that  there  is  a loss  in 
overall  service  capability  that  is  less  than  the  proportionate 
reduction  in  bit  rate  in  going  from  a Tl  carrier  rate  to  the 
experimental  system  transmission  rate  of  230.4  kBPS. 

6. 3. '3  The  Effect  of  a Noisy  Environment  on  the  Data  Traffic  Load 

tT 

Data  traffic  load  will  increase  in  a noisy  environment  due  to 
the  need  for  ARQ  error  control.  This  effect  has  been  examined  in 

paragraph  6.2,  where  a mathematical  model  or  the  effect  of  noise  on 
transmission  efficiency  and  throughput  was  investigated.  Three  types 
of  ARQ  error  control  protocol  were  considered;  Block-by-Block, 
Continuous-Type  I and  Continuous-Type  XI.  Examination  of  the  curves 
in  paragraph  6.2  showed  that  continuous  AI.Q-Type  II,  where  only  the 
packet  in  error  is  retransmitted,  is  the  most  efficient  of  the  three 
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TABLE  6-5.  VARIATION  OF  THE  WAITING  TIME  AND  DATA  UTILIZATION  WITH 

OFFERED  DATA  TRAFFIC  FOR  FIXED  AND  MOVABLE  BOUNDARY  CASES 
T1  CARRIER  RATE 
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forms  of  protocol.  The  other  procedures  require  retransmission  of 
more  data  than  does  continuous  ARQ-Type  II  for  each  error  occurrence. 
This  increases  occupancy  time  in  the  transmit  queue  and  thus  requires 
larger  queues  (more  memory)  on  a per  link  basis.  There  is  also  the 
increased  complexity  associated  with  continuous  ARQ-Type  I where 
validly  received  packets  which  have  been  processed  must  not  be 
processed  a second  time. 

For  a bit  error  rate  of  10-3,  the  optimum  packet  size 
associated  with  block-by-block  ARQ  is  Popt  = 728  bits  and  the 
corresponding  efficiency  is  16.17  percent  (see  Table  6-1).  The  busy 
hour  data  load  is  448  bits  per  frame  (approximately  20  percent  of  the 
total  frame  size) . The  peak  equivalent  data  load  in  this  noise 


environment  is 


443 


=*  2771  bits.  This  means  that  because  of  the 


.1617 

inefficiency  of  data  transfer  in  this  high  noise  environment,  it  would 
take  more  bits  than  are  available  for  the  entire  frame  to  transmit  the 
two  data  packets.  Since  this  exceeds  the  frame  capacity,  an  overflow 
condition  would  exist  resulting  in  an  infinite  queue. 

Under  the  same  conditions,  i.e.,  a bit  error  rate  of  10-3,  the 
optimal  packet  size  for  Continuous  ARQ-Type  I is  Popt  = 314  bits  and 

the  efficiency  is  27.44  percent.  The  peak  data  load  for  this  case  is 
448 

~2T4¥=  *633  bits.  This  still  results  in  an  overload  condition 
because,  besides  the  two  packets,  the  frame  is  also  required  to 
accommodate  during  the  busy  hour,  four  erlangs  of  voice,  an  SOF 
marker,  one  CCIS  message  and  10  bits  for  bit  stuffing.  These  results 
tend  to  indicate  the  impracticality  of  using  block-by-block  or 
Continuous  Type  I ARQ  over  a noisy  wideband  link. 
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6.4  SYSTEM  SIZE  AND  TRAFFIC  HANDLING  CAPABILITY 

In  a conventional  switching  system  sizing  is  usually  defined 
by  the  quantities  of  lines,  trunks,  and  service  connections 
accommodated  by  the  switcn,  for  a'  specified  level  of  traffic.  In  the 
SENET-DAX  concept,  however,  various  classes  of  traffic  are 
accommodated,  each  of  which  are  composed  of  different  transmission 
rates.  This  kind  of  system  is  more  appropriately  sized  in  terms  of 
throughput,  with  the  trunk  transmission  rate  providing  the  basic  unit 
of  throughput  and  the  corresponding  system  size  that  generates  that 
throughput  providing  the  unit  of  system  expansion. 


Ir.  order  to  calculate  the  number  of  voice  and  data  subscribers 
served  by  the  model,  the  following  assumptions,  based  on  1985  DOD 
projected  statistics,  [26],  are  made  for  voice  traffic: 


An  average  holding  time  of  3 minutes  for  local  calls  and 
5 minutes  for  trunk  calls 


b.  A call  distribution  by  transmission  rate  given  by: 


10  percent  at  2400  BPS 
10  percent  at  4000  BPS 
15  percent  at  8000  BPS 
50  percent  at  16,000  BPS 
10  percent  at  32,000  BPS 
5 percent  at  5C.000  BPS 


(vocoder) 

(LPC) 

(APC) 

(CVSD) 

(CVSD) 

(KY3) 


c.  All  calls  are  full-duplex. 

Based  on  these  assumptions,  the  effective  weighted  transmission  rate 
is  15,540  BPS  and  the  average  number  of  bits  in  a frame  per  voice  call 
is  155.4.  Assume  that  80  percent  of  the  frame  is  used  to  carry  voice 
traffic.  Then  4 erlangs  of  voice  traffic  with  a grade-of-service  of 
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0.1  percent , 1 CCIS  message,  and  2 data  packets  224  bits  in  length 
with  insignificant  delay  can  be  accommodated  during  the  busy  hour  on  a 
single  230.4  kBPS  link. 

The  number  of  voice  subscribers  that  generate  a trunk  traffic 
of  4 erlangs  can  be  determined  from  the  expression 

A 


NV  = a 


(6-18) 


where  A is  the  total  two-way  traffic  in  erlangs  for  the  N voice 
subscribers  and  a is  the  two-way  traffic  in  erlangs  for  each 
subscriber.  Assuming  a distribution  of  two-thirds  of  the  traffic 
carried  over  the  trunk,  i.e.,  line-to-trunk  and  trunk-to-line ; and  the 

rest  carried  as  local  traffic,  Nv  is  calculated  as  follows: 

2A 

3=4  erlangs 


and 

Given 


A = 6 erlangs. 

a = .3  erlangs 
6 

Nv  = = 20  voice  subscribers 


The  number  of  data  subscribers  that  can  be  supported  is  equal 
to  the  total  data  traffic  on  the  link  divided  by  the  average  data 
traffic  per  subscriber  terminal.  The  data  trunk  traffic  is  44.8  kPBS. 
Assuming  that  this  is  two-thirds  of  the  total  data  traffic  on  the 
link,  the  total  becomes  1.5  x 44,800  bits/sec.  Let 
No  = number  of  data  terminals 

^ = total  number  of  two-way  messages  per  busy  hour 
£ = average  message  length  (bits) 


Then 


N_  = (1.5  x 44,  800)  (3600) 


D 


XI 


(6-19) 


From  reference  [26]  * = 24  messages  per  busy  hour,  and  = 28,000 
bits  per  message.  Therefore 

„ _ (1.5  X 44,800)  0600)  

nd (24)"  (28000] 360  data  subscribers. 

Thus  the  single  230.4  kBPS  link  has  the  capacity  to  support  up  to  20 
voice  subscribers  and  360  data  subscribers.*  Since  the  minimum  system 
size  can  be  considered  in  terms  of  one  230.4  kBPS  trunk,  where  the 
link  has  been  defined  as  the  ability  to  carry  local  traffic  generated 
according  to  the  assumptions  made  earlier,  a single  switch  can  handle 
a maximum  of  380  subscribers.  The  system  architecture,  however,  is 
flexible  enough  to  allow  a lesser  subscriber  population  and  a higher 
concentration  of  (partially  used)  230.4  kBPS  trunks  to  other  nodes. 

The  maximum  size  of  the  model  has  been  designed  to  accommodate 
up  to  five  230.4  kBPS  trunks  (see  Section  3).  In  Section  2 it  was 
shown  that  this  requires  a memory  access  cycle  time  of  248 
nanoseconds,  assuming  typical  program  complexity  (see  Figure  2-1, 
distributed  curves,  Ap  = 15  access/byte) . Since  state-of-the-art 
cycle  times  for  solid  state  memories  are  in  the  order  of  100  nsec,  our 
requirements  are  well  within  the  range  necessary  for  available, 
off-the-shelf  hardware. 


* The  calculation  of  these  quantities  did  not  take  into  account  either 
the  movable  boundary  or  the  increase  in  data  resulting  from  ARQ  in  a 
noisy  environment. 
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Traffic  handling  characteristics  of  the  experimental  system 
are  tabulated  in  Table  6-6.  It  is  assumed  that  each  node  services 
three  230.4  kBPS  trunks.  Upper  bound  calculations  for  Class  I assume 
that  the  entire  frame  is  reserved  for  voice  except  for  the  SOF  flag 
and  enough  capacity  to  send  one  CCIS  message.  Upper  bound 
calculations  for  Class  II  data  packets  assume  that  2 packets  can  be 
processed  per  link  during  each  frame  with  less  than  .1  ms  queueing 
delay. 


6.5  CROSS-OFFICE  AND  CROSS-NETWORK  DELAYS  FOR  TYPICAL  VOICE  AND  DATA 
TRAFFIC 

Cross-office  and  cross-network  delays  are  important  measures 
of  any  switched  network  and  depend  upon  the  topology  of  the  network 
and  the  processing  capability  of  each  of  the  constituent  switching 
nodes*  For  the  experimental  SENET-DAX  network,  operational  limits  on 
delay  can  be  classified  according  to  the  distinct  classes  of  traffic 
which  the  network  will  be  required  to  carry.  Class  I terminals 
operate  synchronously  such  that  once  the  information  flow  is 
established,  it  continues  for  the  duration  of  the  call.  Typical 
examples  are  voice  and  facsimile.  These  calls  remain  unaffected  as 
long  as  cross-network  delays  are  less  than  about  250  msec.  Class  II 
interactive  TTY  and  query/response  terminals  are  conveniently  handled 
by  packet-switching  techniques.  These  calls  generally  require  delays 
on  the  order  of  a second  or  less  for  responsive  operation.  Another 
type  of  Class  II  call  is  bulk  data  transfer,  typified  by 
computer-to-computer  calls  and  the  Autoden  I type  of  record  traffic. 
Here  time  is  not  a critical  factor.  The  message  can  be  delivered  by 
the  network  on  a space-available  basis. 

In  this  section,  cross-office  and  cross-network  delays  will  be 
determined  for  typical  voice  and  data  calls  on  the  experimental 
SENET-DAX  network.  The  examples  to  be  considered  include  a secure  16 
kBPS  Class  I voice  call?  an  interactive  packet-switched  data  call 
between  a terminal  and  computer?  and  a CCIS  message  sequence  used  for 
call  setup.  In  each  example  the  component  elements  in  the  signal  path 
between  the  transmitting  and  receiving  terminals  that  contribute  to 
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delay  are  identified  and  the  delay  estimated.  These  delays  are  then 
accumulated  and  the  cross-network  delay  for  each  type  of  call  is 
specified. 


6.5.1  Cross-Network  Delay  for  16  kBPS  Voice  Call 


Figure  6-10  shows  the  network  connections  associated  with  a 16 
kBPS  secure  voice  conversation.  The  circuit#  which  consists  of  three 
trunks  and  two  subscriber  loops,  was  chosen  to  typify  the  worst-case 
delay  conditions  associated  with  the  4-node  experimental  network. 

This  path  connection  was  also  used  to  demonstrate  other  examples  of 
network  calls,  as  will  become  evident  in  the  paragraphs  which  follow. 

In  this  example  we  assume  that  the  virtual  circuit  has  been 
established  between  subscriber  subsets  along  the  path  shown  and  will 
be  maintained  for  a call  duration  of  5 minutes.  Delay  times 
associated  with  the  component  elements  along  this  path  connection  are 
given  in  Figure  6-10. 

The  total  network  delay  consists  of  the  delays  in  the  sending 
and  receiving  terminals,  the  propagation  delay  over  the  two 
4-kilometer  subscriber  terminal  loops  and  the  three  500-mile  trunks, 
and  the  cross-office  delays  across  each  of  the  four  SENET-DAX 
switches.  The  subsets  are  digital  secure  voice  terminals,  such  as  the 
DVST,  and  use  16  kBPS  continuous  variable  slope  delta  (CVSD)  modulation 
for  analog-to-digital  conversion.  The  digital  output  is  converted  to 
quasi-analog  form  by  a conditioned  diphase  modem  for  transmission  over 
the  loop  to  the  switch.  Figure  6-11A  shows  the  delays  associated  with 
typical  functions  of  the  digital  secure  voice  terminals.  Individual 
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Figure  6-10.  Cross-Network  Delay  for  16kBPS  Voice  Call 


blocks  were  described  in  the  Phase  I Final  Report  [26]  and  estimates 

of  delay  were  made.  The  terminal  delay  from  the  time  that  the  first 

bit  of  the  signal  enters  the  output  buffer  until  it  is  emitted  by  the 

modem  and  propagates  down  the  loop  is  7 bit  times.  This  corresponds 

/ 

to  a sending  and  receiving  terminal  delay  of 


7 bits 

rSL  = 16  kBPS 


.4375  msec. 


The  propagation  delay  of  trunks  and  loops  are  calculated 


according  to  the  formula 


Td  = /£  (L) 


(6-20) 


where  L is  the  path  length,  e is  the  dielectric  constant  of  the 
medium,  and  c is  the  velocity  of  light  (3  x 108  meter s/second) . The 
propagation  delay  is  defined  as  the  time  required  for  a signal  to 
travel  down  a sending  or  receiving  trunk  or  loop.  This  time  is  less 
for  microwave  radio  or  satellite  than  it  is  for  coaxial  cable. 

However,  in  order  to  "upper  bound"  all  propagation  delays  calculated 
for  the  experimental  system,  trunks  will  be  considered  to  be  coaxial 
cable  and  loops  will  be  twisted-pair  field  wire,  such  as  WF-16.  For 
these  conditions,  the  500  mile  trunk  propagation  delay  is  TP^r  = 4.25 
msec  and  the  4 kilometer  loop  propagation  delay  is  TpL  = .021  msec. 

The  functional  components  which  contribute  to  cross-office 
delay  at  the  SENRT-DAX  node  are  shown  in  Figure  6-llB.  This  figure 
illustrates  the  interface  between  the  switch  and  the  230.4  kBPS  trunk 
circuit  and  between  the  switch  and  the  16  kBPS  loop.  The  cross-office 
delay  is  given  by 
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TC  - TRL  + TH  + TST 

and  is  the  sum  of  the  delays  in  the  receiving  and  sending  interface 
units  and  the  processing  delay  of  the  switch.  This  figure  shows  an 
originating  switch  where  the  receiving  interface  is  a loop  and  the 
sending  interface  is  a trunk.  For  tandem  nodes  both  the  receiving  and 
sending  interfaces  are  trunks. 

The  receiving  loop  interface  delay  consists  of  the  delay  in 
the  modem,  crypto  and  the  decoder/line  termination  unit  and  is  assumed 
to  be  6 bit-times.  The  signaling  delay  of  1 bit  for  CVSD  is  included 
in  the  sending  interface  delay.  Assuming  an  average  polling  delay  in 
the  Decoder/LTU  of  one-half  of  the  load  period  at  a 16  kBPS  rate,  the 
value  of  TRL  *s  estimated  to  be  .4688  msec.  the  transmitting 

trunk  interface  delay,  consists  of  the  delay  in  the  modem,  crypto,  and 
coder  blocks  plus  the  time  necessary  to  transmit  the  160  bits  of  the 
voice  channel  onto  the  line.  Assuming  6 bit-times  of  delay,  or  4 

microseconds,  for  the  modem,  crypto,  and  coder,  the  value  qz  ^or  a 
16  kBPS  voice  channel  in  a 230.4  kBPS  trunk  is  911  microseconds. 

Figure  6-12  shows  the  detailed  processing  functions  of  the  Coder  and 
Decoder  in  terras  of  the  link  processing  structure  of  the  experimental 
system. 


The  processing  delay  is  given  by 


TH  - *OB  + TP  + TIB 


(6-22) 


and  consists  of  input  and  output  buffer  delays  and  the  delay  due  to 
processing  the  160  voice  bits  per  frame.  Ko  queues  will  be  formed  for 
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Class  I calls  during  overload  since  any  surplus  calls  are  blocked. 
Therefore,  the  only  delays  for  Class  I traffic  will  be  the  polling 
delays  in  the  input  and  output  buffers. 

The  input  processor  will  effect  transfer  of  the  160  bits  per 
frame  to  the  input  buffer.  This  information  is  accumulated  until  a 
complete  160  bit  segment  is  received.  Assuming  a 230.4  kBPS  data  rate 
for  the  trunk,  the  entire  160  bits  will  be  transmitted  in  0.69  msec 
starting  at  some  random  point  in  the  Class  I region  of  the  10  msec 
frame.  This  position  will  change  during  the  course  of  the 
conversation  as  calls  are  completed  and  the  Class  I region  is 
recompacted.  Tne  delay  in  transmitting  the  first  bit  on  the  output 
trunk  is  random,  varying  from  0 to  a complete  10  msec  frame.  The 
average  delay  is  one-half  the  frame  interval,  or  5 msec.  Thus  the 
total  processing  delay  will  consist  of  the  10  msec  frame  interval  plus 
this  stochastic  component,  for  a total  of  15  msec  per  node.  The  range 
will  vary  from  10  to  20  msec,  with  a variance  per  node  of  .833  msec 
(assuming  a uniform  distribution  for  the  random  component) . The 

average  cross-office  delay  of  a node  becomes  Tc  = 15  + .4688  + ,911  = 
16.38  msec. 
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For  the  case  of  end  nodes,  an  additional  millisecond  is 
included  to  account  for  buffering  capacity  necessary  to  allow  for 
propagation  delay  variations  and  clock  drifts  during  fades.  The 
additional  time  is  arbitrarily  assigned  to  Tob  and  would  allow  for 
variations  up  to  16  bits  during  a fade  or  due  to  propagation 
anomalies.  This  adjustment  is  only  necessary  at  the  originating  and 
terminating  nodes. 
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The  resultant  cross-network  delay  after  the  connection  has 
been  established  is  81.19  msec.  Of  this  total,  12.79  msec  represents 
the  propagation  delay  over  the  1500-mile  circuit,  .875  represents  the 
total  of  the  transmitting  and  receiving  terminals,  and  67.52 
represents  the  cross-network  delays  of  the  switches  (34.76  msec  for 
the  two  terminal  nodes  and  32.76  for  the  two  tandem  nodes).  The  only 
stochastic  element  in  the  delay  is  the  half-frame  expected  value  of 
delay  from  the  time  the  block  of  160  bits  is  received  until  it  is 
inserted  in  its  slot  in  an  output  trunk.  Assuming  this  delay  to  be 
uniform  over  the  frame  interval  and  the  cross-network  delay  to  be 
normally  distributed  around  81.19  msec,  the  cross-network  delay  for 
the  1500-mile  voice  call  would  be  88.7  msec  at  a 90  percent  confidence 
level  and  98.53  msec  at  a 99.7  percent  confidence  level. 


6.5.2  Cress-Network  Delay  for  Packet-Switched  Data 


In  this  example  an  interactive  data  call  between  a 110  BPS 
teletype  and  a computer  is  sent  over  the  network  as  packet-switched 
Class  II  traffic.  Figure  6-13  shows  the  path  connection  for  the  call. 
A terminal  message  length  of  2000  bits  is  assumed.  The  message  is 
transmitted  over  a circuit  which  includes  two  4-kilometer  subscriber 
loops  and  three  500-mile  trunk  links.  For  the  purposes  of  the 
experiment,  the  computer  may  be  emulated  by  substituting  the  nodal 
processor  at  one  of  the  nodes  in  place  of  a teletype  terminal  at  the 
interface  to  a Class  II  access  processor. 
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Figure  6-13.  Cross-Network  Delay  for  Interactive  Data  Call 
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A distribution  of  80  percent  for  voice  traffic  and  20  percent 
for  data  traffic  is  assumed.  This  provides  an  effective  Class  XI 
transmission  rate  of  44.8  kBPS  on  the  trunks.  Each  link  is  500  miles 
long  and  has  a propagation  delay  of  4.25  msec.  Bit  error  rates  on  the 
link  are  10~5  and  10"^  except  during  bursts  of  0.5  percent  duty  cycle, 
during  which  time  the  error  rate  is  so  high  as  to  make  the  trunk 
useless  for  transmission.  Noise  bursts  last  from  2.5  to  50  msec  and 
are  spaced  from  50  msec  to  one  second.  Loops  are  4 km  in  length  and 
have  propagation  delays  of  .021  msec.  Loop  error  rates  are  10“^  with 
a burst  duty  cycle  of  .0005.  Peak  hour  voice  load  is  4 erlangs.  Peak 
hour  data  load  is  200  packets/second,  packets  are  224  bits  in  length, 
and  Continuous  ARQ-Type  II  protocol  is  used  for  error  control. 


The  entire  2000-bit  message  is  first  transmitted  to 
originating  Node  A,  where  it  is  broken  up  and  formed  into  packets.* 
Packets  are  then  transferred  across  the  network  to  the  terminating 
switch  D.  Packets  transmit  the  network  independently  of  each  other. 
At  the  terminating  node  D,  the  message  is  reformed  and  delivered  to 
its  destination.  Node  D keeps  track  of  all  packets  in  a multipacket 
message  and  will  not  send  data  to  the  computer  until  all  packets  are 
in  the  output  buffer. 


♦Actually,  packetizing  can  take  place  before  the  entire  message  is 
received  at  A,  A buffer  is  set  up  at  A,  and  as  this  becomes  filled, 
the  contents  are  packetized  and  transferred  along  the  network. 
However,  because  the  optimum  size  of  this  buffer  has  yet  to  be 
determined,  and  because  the  delays  due  to  the  network  portion  of  the 
path  are  the  same  for  both  cases,  we  will  assume,  for  convenience, 
receipt  of  a complete  message  prior  to  packetizing. 
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Data  packets  will  have  an  information  field  variable  up  to  164 


bits  per  packet  (60  bits  are  used  for  overhead)  and  continuous  ARQ 
error  control,  with  repeat  of  only  the  packet  in  error.  The  2000-bit 
message  will  therefore  be  transmitted  as  13  packets,  all  except  the 
last  having  224  bits.  However,  the  number  of  packets  which  have  to  be 
transmitted  in  order  to  insure  that  13  are  received  correctly  is  a 
function  of  packet  length  and  bit  error  rate.  This  is  described  by 


the  negative  binomial  law  and  by 

N - SSL  + r 


(6-23) 


where  nq  is  composed  of  r,  the  number  of  trials  required  to  achieve 
the  rth  success  plus  the  number  of  failures  encountered  before  the  rth 
success  is  met,  and  c is  the  standard  deviation.  For  99.7  percent 
confidence,  16  packets  would  have  to  be  sent  to  be  confident  that  13 
packets  were  received  correctly. 


The  input  queueing  delay  at  a node  was  estimated  by  the 
Pollaczek-Kintchin  formula  1 

p 

Tqi  ■ rrr^-?) 


1 + 


(l/y) 


(6-24) 


. 2 . 

where  p is  the  utilization  factor ,1/uis  the  service  time,  and  0 is 

& 

the  variance  of  the  service  time.  The  maximum  packet  rate  which  the 
switch  will  ever  see  on  one  link  will  be  500  packets/second  or  2 msec 
per  packet.  Assuming  a processor  utilization  factor  of  ,7,  the 


queueing  delay  becomes  t ^ = 2.  543  ms  per  queue. 


After  the  packet  is  processed  at  a node  during  the  10  msec 
incoming  frame#  it  is  placed  at  some  position  in  the  Class  II  region 
of  the  next  10  msec  outgoing  frame*  This  position  is  random  but  is 
most  probably  in  the  latter  half  of  the  frame  because  of  Class  I 
traffic.  In  the  absence  of  Class  I traffic  the  packet  would  directly 
follow  the  SOF  marker.  However,  for  a 90  percent  voice/10  percent 
data  distribution  and  a full  10  msec  frame,  the  packet  would  appear  in 
the  last  10  to  12  percent  of  the  frame.  Therefore,  we  will  neglect 
the  stochastic  variation  and,  as  an  upper  bound,  consider  Tjj , the 
processor  delay,  to  be  20  msec. 

Tst  and  Trt  are  computed  to  be  TgT  = = 5.134  msec 

and  Trt  = = .145  msec.  respectively. 

It  takes  18.24  seconds  to  transmit  the  2000-bit  message  to  node  A via 
the  110  baud  line  and  6,69  seconds  to  transmit  it  from  terminating 
node  D to  the  computer.  Other  delays  are  calculated  as  for  the  16 
kBPS  voice  call  in  paragraph  6.5.1. 

As  shown  in  Figure  6-13,  the  cross-network  delay  of  the 
message  is  268.21  msec.  This  assumes  a worst-case  solution  with  one 
packet  released  each  frame  interval,  or  every  10  msec.  The  delay  is 
the  time  necessary  to  release  ail  but  one  packet  (150  ms)  plus  the 
time  it  takes  for  the  last  packet  to  transit  the  network  (118*2  msec). 
When  the  terminals  and  transmission  loops  adjacent  to  the  network  are 
considered,  the  overall  delay  increases  to  25.28  sec. 


A satellite  link  between  nodes  B and  C would  cause  the 
propagation  delay  for  that  link  to  become 


~ 24000  miles 


PTR  .6  kilometers  v „ ,ft8  . 

— X 3 x 10  m/sec 


= 266.67  msec. 


mile 


This  would  result  in  a cross-network  delay  of  530.63  msec  for  the 
interactive  data  call. 


If  the  terminal  and  computer  were  capable  of  2400  BPS  and  64 
kBPS,  respectively/  the  overall  delay  (including  loops  and  terminals) 
would  decrease  from  25.28  seconds  to  1.132  seconds  without  the 
satellite  link  and  1.395  seconds  with  the  satellite  link  included. 
Substituting  a 9600  BPS  terminal  for  the  2400  BPS  terminal  would  then 
cause  this  overall  delay  to  decreae  to  507.79  msec.  Even  with  the 
satellite  link,  the  delay  (707.21  msec)  would  still  be  less  than  a 
second. 

6.5.3  Impact  of  Transmission  Rate  on  Cross-Network  Delay 

In  order  to  evaluate  the  impact  of  the  lower  transmission  rate 
used  in  the  experimental  system,  a comparison  of  cross-network  delays 
for  various  packet  lengths  was  made  for  the  230.4k  and  1.544  MBPS 
transmission  links.  The  following  constraints  were  specified  to  allow 
for  a meaningful  interpretation  of  the  results: 


a.  One  packet  is  transmitted 

b.  Class  II  transmission  rates  are  20  percent  and  50 
percent  of  the  carrier  transmission  rate 

c.  The  bit  error  rate  is  10"^ 

d.  Packet  lengths  vary  from  224  to  1024  bits 
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e.  The  transmission  of  packets  in  the  error  environment  is 
described  by  the  negative  binomial  law.  A confidence 
level  of  99.7  percent  is  used. 

f.  Maximum  packet  rate  is  100  packets/second 

g.  The  utilization  factor  is  70  percent. 

The  results  are  given  in  Figure  6-14.  This  shows  the  impact 
on  the  cross-network  delay  when  a 230.4  kBPS  trunk  transmission  rate 
is  substituted  for  the  T1  carrier  rate  used  in  Phase  I.  For  these 
typical  packet  lengths,  the  curves  track  one  another  closely.  At  the 
packet  length  of  224  bits  (the  suggested  operating  condition) , the 
impact  of  the  lower  transmission  rate  on  the  delay  is  minimal  (less 
than  4 percent) . 


6.5.4  Cross-Network  Delay  for  CCIS  Message  Sequence 
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In  tir<s  example  we  will  examine  the  cross-network  delay  of  the 
CCIS  message  sequence  associated  with  setting  up  a Class  I voice  call. 
The  maximum  CCIS  message  length  of  232  bits  is  used  and  corresponds  to 
a 23,2  kBPS  transmission  rate.  Trunk  sending  and  receiving  terminal 
delays  are  10.259  msec  and  0.28  msec,  respectively.  Queue  waiting 
time  and  cross-office  delays  are  taken  to  be  the  same  as  those 
specified  in  Figure  6-12,  The  call  scenario  is  as  follows  (see  Figure 
6-15) : 


11 


Calling  subscriber  at  switch  A dials  last  digit 
Reserve  A-B  Channel  (F)* 

Reserve  B-C  Channel  (F)/A~B  channel  reserved  (B) 

Reserve  C-D  Channel  (F)/B-C  channel  reserved  (B) 


*F  = forward  direction,  B = backward  direction 


Ring  forward  to  subscriber 


Ringback  CCIS  message  D-C  (B) 


Ringback  CCIS  message  C-B  (B) 


Ringback  CCIS  message  B-A  (B) 


Called  subscriber  goes  off-hook 


Allocate  D-C  channel  (B) 


Allocate  C-B  channel  (B)  ,/D-C  channel  allocated  (P) 


Allocate  B~A  channel  (B)/C~B  channel  allocated  (P) 


A-B  channel  allocated  (F) , ringback  removed,  2-way 
conversation  enabled. 


Seven  CCIS  messages  (packets)  are  sent  in  one  direction  during 
the  call  setup.  However,  to  be  99.7  percent  confident  that  7 messages 
will  be  received  correctly  in  this  error  environment,  an  average  of  12 
messages  must  be  transmitted.  Thus,  12  single  CCIS  messages 
multiplied  by  the  cross-network  delay  of  each  message  yield  an  overall 
delay  of  1.608  seconds  for  call  setup  time  (see  Figure  6-15). 
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Figure  6-15.  Cross-Network  Delay  for  CCXS  Message  Sequeuce 
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SECTION  7 


COST  ESTIMATES  FOR  EXPERIMENTAL  HARDWARE  AND  OFF-LINE  SOFTWARE 


7.1  SYSTEM  BASIS  FOR  COSTING 


Each  nodal  system  is  assumed  to  contain  a nodal  overhead 


.v 


eauiproent  group,  a link  termination  equipment  group,  and  an  access 


equipment  group.  The  laboratory  network  will  require  one  master  clock 


to  operate  all  nodes.  Data  memory  sizes  required  at  link  and  access 
ports  are  indicated  in  Figure  3-3,  where  the  program  memory  and 
peripheral  interfaces  needed  by  each  of  the  distributed  processors  are 
also  shown. 


yv. 


Estimates  include  three  ASR  33  teletypes  per  node.  These 
teletype  machines  would  function  as  a Class  II  data  terminal,  a Class 


I/II  dummy  traffic  controller,  and  a vehicle  for  node  statistical 
printouts  and  processor  program  administration.  In  the  minimum 
two-node  network  configuration,  only  one  link  termination  equipment 


: 


group  is  required  per  node.  Therefore  it  is  anticipated  that  only  one 


full-size  equipment  rack  will  be  needed.  With  the  addition  of  a 
second  link  termination  group  per  node,  as  in  the  three-  and  four-node 
network  configurations,  a second  equipment  rack  would  be  required  at 
each  node. 
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7.2  EQUIPMENT  VENDORS  SURVEYED 


The  information  on  network  costing  has  been  compiled  from  data 
derived  from  Digital  Equipment  Corporation  for  the  LSI-11 
microcomputer,  and  from  Data  General  Corporation  for  the  MNOVA 
microcomputer  family.  Costs  have  been  quantity  discounted  on  the 
basis  of  a minimum  experimental  network  of  two  nodes. 

7.2.1  DEC  LSI-11 

The  LSI-11  microcomputer  family,  manufactured  by  Digital 
Equipment  Corporation,  contains  a complete  line  of  hardware,  software 
support,  and  an  off-line  software  development  system.  To  the  hardware 
cost  estimates  is  added  an  amount  of  $13,751.00  for  off-line  software 
development.  This  development  system  incorporates  the  BASIC  language, 
has  a multi-user  capacity  for  two  DECwriter  units  and  a DECprinter, 
and  can  remotely  transfer  a developed  program  via  a serial  line 
interface  (SLI)  into  a distant  processor. 

7 . 2 . 2 . Data  General  uNOVA 

The  NOVA  microcomputer  family,  manufactured  by  Data  General 
Corporation,  contains  a complete  hardware  line  with  some  software 
support.  Data  General  has  indicated  that  an  off-line  software 
development  system,  having  a capability  similar  to  the  DEC  off-line 
development  system,  would  cost  approximately  $20,000  to  $25,000. 
Consequently,  the  network  cost  estimates  include  an  average  cost  of 
$22,500  for  Data  General  off-line  software  development. 


7.3  COST  SUMMARY 


Cost  estimates  were  made  of  the  experimental  SENET-DAX  model 
for  various  network  configurations.  These  costs,  based  upon  the 
detailed  cost  information  presented  in  Appendix  II,  are  summarized  in 
Tables  7-1,  7-2,  and  7-3  for  two-,  three-,  and  four-node  experimental 
systems.  The  information  presented  here  pertains  only  to  processor 
equipment  costs  and  to  off-line  software  development  system  costs. 

Note  that  costs  for  development  of  on-line  operational  software  and 
other  non-recurring  engineering  and  development  have  not  been  included 
in  this  estimate.  Neither  has  the  cost  of  terminal  eauipment. 
Preliminary  hardware  costs  of  other  eauipment  remaining  to  be  designed 
in  detail  (nests,  boards,  etc.) , have  also  been  estimated  (see 
Appendix  XX).  In  Appendix  II,  a listing  of  components  that  make  up 
the  respective  groupings  is  presented  along  with  itemized  costing 
information.  By  specifyina  the  eauipment  needed  for  a particular 
network  configuration,  it  is  possible  to  arrive  at  the  cost  summaries 
in  Tables  7-1,  7-2  and  7~3  from  the  cost  date  supplied  in  Appendix  II. 


It  appears  that  both  microcomputers  are  capable  of  satisfying 
the  operational  hardware  and  software  system  requirements  of  the 
experimental  model  at  a comparable  network  cost.  Further 
investigation  would  be  necessary  wit'.:  respect  to  the  performance  of 
comparative  application-oriented  benchmark  programs  before  a final 
processor  choice  could  be  made. 
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TABLE  7-3.  EXPERIMENTAL  FOUR-NODE  NETWORK 
COST  SUMMARY 


SUBSCRIBERS 


ACCESS/TANDEM 


SUBSCRIBERS 

ACCESS/TANDEM 


INTERSWITCH 


SUBSCRIBERS 
ACCESS/TANDEM 


ACCESS/TANDEM 


SUBSCRIBERS 


SYSTEM 

EQUIPMENT 


ACCESS  EQUIPMENT  GROUP 

NODE  POWER  SUPPLY  & 
CABINETS 

LINK  TERMINATION  GROUP 

NOD  \L  PROCESSOR  GROUP 

DOUBLE  OVEN  CLOCK 

PROM  PROGRAMMER 

OFF-LINE  SOFTWARE 
DEVELOPMENT  SYSTEM 


COST 

LSI-II  MICROCOMPUTER 
TECHNOLOGY 

V NOVA  MICROCOMPUTER 
TECHNOLOGY 

$ 63,132 

$ 62,592 

5,200 

5,200 

117,190 

109.240 

28,336 

27,244 

800 

800 

1,700 

1,700 

13,751 

22,600 

4230,109 

§229,276 

SECTION  8 


FURTHER  NETWORK  CONSIDERATIONS 


8.1  GENERAL 


The  next  logical  step  in  this  program  is  the  experimental 
implementation  of  the  SENET-DAX  concept  of  a limited  multinode 
network.  This  would  allow  the  techniques  established  during  the  phase 
just  concluded  and  during  the  previous  Phase  I study  to  be  implemented 
and  evaluated  in  software  and  hardware,  and  analytic  tradeoffs 
investigated  experimentally.  Certain  additional  areas,  however,  have 
great  potential  application  toward  the  realization  of  an  experimental 
SENET-DAX  network  and  are  discussed  in  the  following  sections.  These 
include  communication  over  satellite  links  and  interface  with  the  ARPA 
network. 


8.2  SATELLITE  COMMUNICATIONS 


The  networks  of  .interest  for  the  application  of  the  SENET-DAX 
concept  are  already  of  global  proportions  and  it  appears  that  this 
trend  will  continue  in  future  communication  networks.  For  example, 
both  the  AUTOVON  and  AUTODIN  communication  networks  are  currently  of 
intercontinental  scope,  while  networks  such  as  the  ARPANET  are  already 
of  transcontinental  scope.  In  order  to  provide  such  global  networks 
economically,  extensive  use  of  satellite  links  to  supplement  or 
replace  landline  or  radio  links  between  switching  nodes  is  foreseen 
15].  Over  the  past  few  years  satellite  communication  has  experienced 
rapid  advances  resulting  in  a untinuing  decrease  in  satellite  cost. 
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In  fact,  studies  have  shown  that  a potential  cost  savings  of  perhaps 
as  much  as  50  percent  are  achievable  from  the  utilization  of  satellite 
capacity  at  the  expense  of  terrestrial  capacity  [17].  Terrestrial 
facilities  would  still  be  necessary  in  order  to  achieve  a high  level 
of  survivability  for  critical  functions  such  as  command  and  control. 
Thus  it  would  still  be  necessary  to  provide  switching  facilities  in 
the  access  area  to  switch  between  terrestrial  transmission  systems. 
However,  the  proportion  of  traffic  carried  by  terrestrial  circuits 
relative  to  that  carried  by  the  satellite  would  decrease. 
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Satellite  systems  organized  in  a multiple  access  arrangement 
in  which  multiple  users  communicate  over  common  satellite  channels  are 
expected  to  be  very  attractive  for  use  in  packet  data  communication 
networks  [23].  These  can  be  divided  into  two  general  categories.  In 
the  first  category  bandwidth  is  divided  among  users  by  FDM  or  TDM 
techniques  into  fixed  allocations  with  each  user  permanently  assigned 
a fixed  portion  of  the  total  available  transponder  bandwidth.  In  the 
second  category  user  channel  assignments  are  dynamically  allocated,  in 
response  to  user  requests,  either  by  means  of  a central  control 
station,  the  ground  stations  themselves,  or  a random  access  method  of 
assignment.  The  class  of  dynamic  channel  assignment  which  does  not 
use  a central  control  is  the  one  which  has  generated  considerable 
interest  for  packet  data  communications.  It  should  be  noted  however, 
that  further  study,  particularly  in  the  area  of  system  control  during 
crisis  conditions,  is  necessary  before  the  use  of  satellite  ground 
stations  in  military  networks  can  be  made  widespread. 
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The  combining  of  integrated  voice/data  switching  with 
satellite  capabiity  could  have  far-reaching  consequences  on  the 
network  topology  and  architecture.  Figure  8-1  illustrates  the 
evolutionary  possibilities  for  our  experimental  four-node  network  in 
which  a fully-connected  distributed  satellite  network  is  overlayed 
onto  the  present  network  structure.  The  SENET-DAX  nodes  typify  small 
size  access  switches  feeding  a highly  interconnected  backbone 
structure  of  tandem  switches  and  interconnected  trunk  circuits.  The 
latter  could  be  AN/TTC-39's,  AUTOVON  switches , or  other  elements  of 
the  present  DCS  network.  The  configuration  allows  the  extension  of 
integrated  voice  and  data  switching  and  multiplex  techniques  into  the 
access  area  and  pro  ides  satellite  communication  capability  as  well. 

It  also  provides  an  experimental  tool  for  extending  the  AUTODIN  II 
network  to  have  overseas  packet  capabilities  and  for  providing 
medium-sized  access  area  concentrators  for  later  extensions  of  the 
Phase  II  Secure  Voice  program  [5].  Eventually  a network  composed  of 
satellite  links  and  access  switches  would  emerge  in  which  subscribers 
in  the  access  area  would  have  significantly  better  user  service 
capability.  The  backbone  structure,  however,  could  continue  for  an 
indefinite  transition  period  and  evolve  as  future  requirements  change. 

During  the  experimental  phase  one  satellite  link  at  a T2 
carrier  rate  (6.312  MBPS)  will  provide  the  necessary  capacity  for  full 
connectivity  of  a four-node  integrated  voice/data  network.*  A dynamic 

* Full  connectivity  of  a four-node  network  requires  six  links,  each 
operating  at  a transmission  and  receiving  rate  of  23Q.4kBPS. 

Therefore,  a capability  of  2 x 230.4  x 6 = 2.7648MBPS,  is  required. 
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variable  transmission  rate,  software  controllable,  from  23Q.4kBFS  down 
to  some  minimum,  could  also  be  developed  so  that  only  the  capacity 
which  contains  real  information  is  transmitted  over  the  satellite 
link. 


8.3  INTERACTION  WITH  THE  ARPA  COMPUTER  NETWORK 


m 


A potential  area  of  application  during  an  experimental  phase 
is  the  interaction  between  the  four-node  experimental  network  and  the 
ARPA  network.  The  ARPA  network  is  a complex,  distributed, 
packet-switching  network  implemented  by  a set  of  small  processors 
called  Interface  Message  Processors  (IMP's)  interconnected  by  50  kBPS 
common  carrier  circuits  [6,10,16],  Its  primary  goal  is  to  permit 
personnel  and  program  at  any  node  in  the  network  to  access  data  and 
software  from  remote  processors  elsewhere  in  the  network.  One 
possible  experiment  which  could  be  used  to  demonstrate  the  flexibility 
of  the  SENET-DAX  approach  would  be  to  carry  packet  data  traffic 
generated  by  the  ARPA  network  over  SENET-DAX  transmission  links  along 
with  voice  and  data  traffic  generated  by  the  SENET-DAX  system.  This 
situation  is  depicted  in  Figure  8-2.  A pair  of  widely  separated  but 
directly  connected  nodes  in  the  ARPA  network  are  chosen  and  outgoing 
traffic  on  the  link  connecting  these  nodes  is  tapped  on  the  trunk 
side.  This  traffic,  which  represents  actual  data  being  transacted  in 
the  ARPA  network,  transits  the  SENET-DAX  experimental  network  and  is 
delivered  to  a tap  on  the  trunk  side  of  the  incoming  ARPA  node  where 
it  is  to  be  decoded.  This  would  demonstrate  that  ARPA  network  traffic 
can  be  transmitted  as  a subset  of  the  voice  and  data  traffic 
transmitted  by  the  SENET-DAX  network.  ARPANET  data  traffic  could  be 


transmitted  either  as  a 50  kBPS  "super-packet  in  the  Class  II  region 
or  else  a full  period  connection  in  the  Class  I region  could  be 
reserved  for  ARPANET  purposes.*  At  the  receive  side  data  would  be  fed 
to  the  terminating  IMP  and  decoded  in  normal  fashion.  An  alternate 
method  is  for  the  ARPA  node  to  receive  traffic  as  it  normally  does 
while  a hard  copy  is  generated  for  comparison  with  the  traffic  sent 
over  the  SENET-DAX  network.  A comparator  which  could  account  for  the 
different  delays  in  the  two  paths  could  verify  that  the  same 
information  was  received  intact  over  the  separate  routes. 

In  this  experiment  SENET-DAX  nodes  need  not  be  concerned  with 
ARPANET  protocol,  format,  error  control,  or  routing  strategy.  The 
entire  SENET-DAX  network  appears  as  just  another  transmission  media  to 
the  ARPA  network.  This  would  not  be  the  case  if  the  interface  were  on 
the  terminal  side  of  the  ARPA  node.  Here  we  would  be  required  to 
emulate  the  IMP,  i.e.,  packetize,  interface  with  the  host  terminal  and 
host  computers,  detect  packets,  etc.  Since  the  ARPA  network  already 
accomplishes  this  function,  no  advantage  would  be  gained  from  doing 
this. 


It  may  be  possible  to  choose  nodes  which  are  co-located  with 
satellite  ground  stations.  Traffic  could  then  be  tapped  from  the  ARPA 
network,  combined  with  voice  and  data  traffic  from  the  SENET-DAX 
experimental  network,  and  fed  into  the  ground  station  for  transmission 


* Although  the  transmission  rate  in  the  ARPA  network  is  50  kBPS, 
actual  data  traffic  is  on  the  order  of  20  kBPS.  Therefore,  it  may  be 
possible  to  reserve  less  capacity  to  handle  ARPANET  traffic  or  even  to 
make  this  allocation  dynamic. 
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APPENDIX  1 :' 

timing  Analysis  tables 
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TABLE  1-1.  ASSUMPTIONS  FOR  TIMING  ANALYSIS 


Traffic 


500  Packets/Sec  (absolute  max) 


200  Packets/Sec  (average  busy  hour) 


13  Calls/100  Sec  (over  3 links) 
Total  Calls 


From 

Performance 
Analysis 
Section  6 


6.5  local  calls/100  sec 


Interrupts 


Real-time  Clock  interrupt  of  1 ms 


4 ms  interrupt  on  Control  Scheduler 


Instruction  Execution  Time/Interrupc  service 


3 vsec/average  instruction  execution  time 


10  usee  Interrupt  Service  Time 


Capabilitv  of  Micro-Processor 


Simple  1 word  accumulator  instructions 


Load,  Store,  Bit  test.  Set  bit,  Add/Subtract 


Branch  conditional,  unconditional  (on  contents) 


Subroutine 


Indexing 


No  multi-indirect  instruction  capability  - 1 level  only 


m: 

mm 
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TABLE  1-2.  CALCULATIONS  FOR  TIMING  ANALYSIS 
FOR  LINK  INPUT  PROCESSOR 

Real-Time  Interrupt  Routine 

(50  instr/int)  (3  psec)  + 10  Psec/int  {1000  int/sec) 

= 160  ms/sec  or  167  percent  loading 


*3 

% 


Control  Scheduler  Module 

(100  instr/cyole)  (3  psec/instr)  + lOR/int)  (250  int/sec) 

= 77.5  ms/sec  or  7.75  percent  loading 

Free  Memory  Background  Scan-List  Management 

OVERHEAD  LOOP  FOR  EACH  ADDRESS 

(10  instr/overhead) (3  Psec) 

+ jf  (30  instr/addr)  (3  p /instr)  (250  address)) 
= 22,5  ms/sec  = 2.25  percent  loading 


Packet  Analysis  Background  Scan 
Instr  Exec  Routine  time  for 

(200  instr/exec)  (3  psec/int) 

= 300  ms/sec  - 30  percent  loading 

Translation  Subroutine 

Instr/Packet  x Instr  Time  x 

(30  instr/packet)  (3  psec/instr) 

= 45  ms/sec  =4.5  percent  loading 

Routing  Subroutine 

Instr/Packet  x Instr  Time  x 

(28  instr/packet)  (3  psec/instr) 

= 42  ms/sec  = 4.2  percent  loading 


# of  packets/sec 
(500  packets/sec) 


# of  packets 
(500  packet/sec) 


# of  packets 
(500  packets/sec) 
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CCIS  Packet  Generation 

Instr/Packet  x Instr  Time  x # of  CCIS  packets/sec 
(80  instr/packet)  (3  usec/instr) (13  calls/lOOsec  x 10  messages) 
= .312  ms  = .03  percent  loading  (negligible) 

Transmit  Packet  Control 

x 


# of  instr/packet  x Instr  Time 
(40  instr/packet)  (3  Usec/instr) 

= 60  ms/sec  = 6 percent  loading 

Acknowledge/No  Acknowledge 

# of  Instr/Packet  x Instr  Time  : 

(50  instr/packet)  (3  ysec/instr) 

- 75  ms/sec  -7.5  percent  loading 

Maintenance  and  Statistics 
t of  instr  exec/pass  x Instruction  Time 

(2000  instr/pass)  (3  ysec/instr) 

“ 6.0  ms/sec  = .6  percent  loading  (negligible) 


# of  packt  *-c/sec 
(500  packets/sec) 


# of  packets/sec 
(500  packets/sec) 


1-3 


O a1 


V*  4 r>.'# 


rl 


-■■  >•; 


.rw. 


•r  •/; 


.;V.'4 


r.  =v  .•>•- r;  i •. : i 


TABLE  1-3.  CALCULATIONS  FOR  TIMING  ANALYSIS 
FOR. LINK  OUTPUT  PROCESSOR 


Real-Time  Interrupt  Routine 


(50  instr/int) 


(3  ysec)  + 10  ysec/int) 


(1000  int/sec) 


160  ms/sec  or  16  percent  loading 


Control  Scheduler  Module 


(100  instr/cycle)  (3  ysec/instr)  + 10y/int)  (250  int/sec)) 


77,5  ms/sec  or  7.75  percent  loading 


Free  Memory  Background  Scan  - List  Management 


OVERHEAD 


LOOP  FOR  EACH  ADDRESS 


(10  instr/overh) (3y/instr)  + [(30  instr/addr) (3u/instr ) (250addr) ] 


22.5  ms/sec  = 2.25  percent  loading 


Background  Queue  Entn 


# of  instr 


Time  for  exec 


# of  packets 


(60  instr/packet) 


(3ysec./instr) 


(500  packets) 


90  ms  = 9.0  percent  loading 


Timeout  Processinc 


of  instr 


Time  for  exec  x # of  bad  packets/sec 


(50  instr/packet) 


(3  ysec/instr) 


(1.1  packets/sec) 


152  ysec  = 15  percent  loading 


Output  Address  Generator 


# cf  instr/packet  x Instruction  time  x # of  packets/sec 


(40  instr/packet) 


(3  ysec/instr) 


(500  packets/sec) 


60  ms  = 6 percent  loading 


Maintenance  & Statistics 


of  instr  exec/pass  x Instruction  time 


(2000  instr/pass) 


(3  ysec/instr) 


6.0  ms/sec  = .6  percent  loading  (negligible) 
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TABLE  1-4.  GENERALIZED  CODE  SET  SAMPLE  OF  LIST 
PROCESSING/TIMING  ALGORITHM 


Problem:  Remove  ith  element  from  one  chained  list  and  add  the 

element  to  the  end  of  another  list.  (e.g.  transmit-to- 
free  list  exchange) 


free  j 

| FRB 

Ptr.  BEG. 

list  ' 

i FRE 

Ptr.  END 

xmit  ! 

( TRB 

Ptr.  BEG. 

1 ist  J 

[ TRE 

Ptr.  END 

Generalized  Code 

Fetch  ~ source,  dest. 

Stor  - source,  dest. 

( ) - one  level  indirect 

addressing 

Avg  instr  exec  time  3.5use.c 


Assumed  Calling  Sequence 


JSR 

Rl,  REMI 

FRB 

or 

TRB 

# in 

list  (i) 

FRE 

or 

TRE 

( i =53 1 v tJ  > 


Subroutine 


REMI: 

STOR 

(Rl)  , TMPI 

INC 

Rl 

FETCH 

(TMPI),  R0 

STOR 

(41),  PTR 

INC 

Rl 

DEC 

PTR 

BNE 

LI  +1 

STOR 

Rtf,  TMP3 

FETCH 

TMPI,  Rtf 

STOR 

Rtf,  SI 

FETCH 

TMP3,  Rtf 

STOR 

Rtf,  S3 

JSR 

Rl,  REMF 

SI: 

WORD 

0 

STOR 

(Rl),  S2 

INC 

Rl 

JSR 

Rl,  ADDE 

S2: 

WORD 

tf 

S3: 

WORD 

RTS 

tf 

LI: 

DEC 

.PTR 

BEQ 

L2 

FETCH 

(Rtf) , Rtf 

Br 

LI 

L2; 

STOR 

(RJJ)  , FP 

STOR 

Rtf , S3 

/FRB  or  TRB  TMP1 

/A1  in  Rtf 
/i  + PTR 

/L  *►  i-1 

/Branch  if  not  1st  el. 

/FRB  or  TRB  +Rtf 
/FRB  or  TRB  +S1 
/AX  R0 
/Al  -»■  S3 

/GO  TO  REMOVE  FIRST 
/FRE  OR  TRE  **  S2 
/GO  TO  ADD  EL  TO  END 


/BRANCH  if  found  ith  element 
/A  2 +RJJ 

/ptr  to  next  element  FP 
/add  of  el.  to  be 
deleted  S3 

/if=0:El.  found  is  last  El. 


TST 


FP 


BNE 

L3 

STOR 

(Rl)  , S4 

/Set  up  last  el.  delete 
/routine  - FRE  or  TRE  S4 

JSR 

Rl,  REML 

S 4 : 

WORD 

0 

/FRE  or  TRE 

BR 

SI  + 1 

L3 

/ith  element  is  neither  1st 
nor  last 

ADD 

BS 1Z , R0 

/loc.  of  back  ptr  of  El  to 
be  deleted  in  R0 

STOR 

(R0) , THP3 

/Prev  El.  ptr  in  TMP3 

FETCH 

FP,  R0 

/Front  pointer  of  element  to 
/be  deleted 

STOR 

R0 , (TMP3) 

/adjust  front  ptr  of  prev. 

El 

FETCH 

FP,  R0 

/front  ptr  to  next  El  Rpf 

ADD 

BSlZ , R0 

/front  of  back  ptr  of  next 
El  in  RJ2 

FETCH 

TMP3 , (R^f) 

/adjust  back  ptr  of  next  El. 

8F 

SI  + 1 

FP: 

WORD 

0 

TMP3: 

WORD 

0 

Timing  Algorithm 

Based  on  position  of  the  element  within  the  table  (ith  position) , 
the  following  chart  provides  several  timing  algorithms  as  a function 


# OF  INSTRUCTIONS  EXECUTION  TIME  (ysec) 


i = 1 45 

i = last  in  list  37  + 3i 

i = not  first  or  last  33  + 3i 


157.5  ysec 

129.5  + (10. 5) i 

115.5  + (10. 5)  i 
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TO  GET  THE  WIDTH  OF 
CLASS  I CHANNEL  REQ. 


8C55-7SE 


Figure  1-2.  Call  Initiate  Message  (Sheet  1 of  3) 


IWW 


Figure  1-2.  Call  Initiate  Message  (Sheet  2 of  3) 
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FROM  CALL 
TABLE 


STORE  IN 
CALLED  AREA 
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FRAME 

CHECK 

SEQ. 


TRANSFER' 
TO  DATA 
.BUS 


SET  TASK  QUEUE  FOR 
CONTROL  SWITCHING 
TO  OUTPUT  PROCESSOR 


8094-7GE 


Figure  1-2,  Call  Initiate  Message  (Sheet  3 of  3) 


Figure  1-3.  Input  Processor  - Stack  Management 


i-ll 


Figure  1-4.  Translation  and  Routing  (Sheet  1 of  3) 
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IS  LINK 
IN  SERVICE 
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ALREADY 
FULL 
? / 


SAVE  AS  INPUT 
TO  FORMAT  CCIS 


A VALID 
LINK  * IS 
SAVED  IN  CALL 
TABLE 


WAS  THIS 
THE  CODE  FOR 
LAST  LINK 

[YES -3 
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CLASSMK 
TABLE 


HAS  THIS 
BEEN  A PREEMPT 
^ ^ 


NO  / BUSY 
TONE 


GET  CALLING 
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LINK  IN 
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IS 
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PRIORITY 
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Figure  1-4.  Translation  and  Routing  (Sheet  3 of  3) 
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Figure  1-5.  LIP  Packet  Analysis  (Sheet  1 of  2) 
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* 
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PR  EC.  IN  ONE  BYTE 

* 
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VIA  DATA  BUS  INSTR. 

i 

GET  LINK 
* FOR  ROUTE 
FROM  TABLE 

SETUP  FOR 
PACKET  FIFO 
AND PORT 
SELECT 

i 

SET  LINK  # 
AND  SELECT 
BITS  FOR  BUS 
ADDRESSING 

’—f 

RETURN  j 

16  ai  r ADDRESS 
* 3 BITS  - MEMORY  PORT 

13  BITS  - ADDRESS 


s 


>5  BITS  — BYTE  COUNT 
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4 
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8101-Ttc 


Figure  1-6.  Control  Switching 
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:Sv 


PLACE  RECEIVED  PACKET  CONTROL 
INFO.  INTO  THE  APPROPRIATE  OUTPUT 
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CONTROL  INFO.  TO  A FREE  LIST  ELEMENT. 


Figure  I**7,  Output  Processor  Control  (Sheet  1 of  2) 
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Figure  1-7.  Output  Processor  Control  (Sheet  2 of  2) 
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Figure  1-8. 


Access  Processor  - Supervision/ 
Signaling  Scan  (Sheet  1 of  5) 


£ 


Figure  1-8 - Access  Processor  - Supervision/ 
Signaling  Scan  (Sheet  4 of  5) 
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TAPLE  II-le  DETAILED  COST  ESTIMATES : DIGITAL  EQUIPMENT  CORPORATION 

LSI -11  WITH  3 TTY /NODE 


LIST 

SYSTEM 

DISCOUNT 

CTV 

ITEM 

PRICE 

PART  NO. 

USAGE(*) 

d) 

COST(* 

Access  Ecoionent  Group 

2 

TTY 

1300 

6 

0 

2600 

2 

LSI -11  fc  4 KV’  RAM 

1696 

ll/$?3-EA 

10 

15 

2883 

4 

4KwRA« 

469 

MFVII-I? 

30 

32 

1276 

7 

Fxosnder  'ox 

808 

PA  1 1 -ME 

10 

32 

1099 

2 

Jumper  Cable 

234 

QCVI5-JI4 

10 

32 

318 

3 

& 

SLI 

235 

DI.VII 

4 

32 

160 

2 

CLVII  Cable 

40 

BC05M-IF 

8 

32 

54 

13 

PLI 

129 

DSVII 

54 

32 

1140 

13 

DPVII  Cable 

32 

BC042-0 

54 

32 

283 

Rpvri-c 

300 

REVII-C 

4 

32 

204 

c 

TEVII 

85 

TEVII 

10 

32 

116 

2 

4?h  Cat  a Memory 

450 

- 

- 

0 

900 

12 

Poards  & Hardware 

270 

- 

- 

0 

3240 

1 

Card  Nest 

350 

- 

- 

0 

350 

** 

£ 

4K  PPCM  Card 

149 

MRVII-AA 

10 

32 

203 

64 

512X4  PPOf*  Chips 

22 

KRVII-AC 

320 

32 

957 

Access  Equipment  G 

roue  T 

otai  Cost 

$15783. 

Node  Fewer  Supply  Cabinets 


1 

Power  Supply  200 

- 

0 

200 

1 

Cabinet  Rack**  550 

Node  Fever  Surely  Cabinet  Total  Cost 

0 

550 

$75C 

* Item  cost  and  svsten  usage  is  based  on  ouantities  needed  for  a 
2-node  network. 

**  2 needed  per  node  for  network  greater  than  2 nodes. 
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TABLE  II-l,  DETAILED  COST  ESTIMATES:  DIGITAL  EQUIPMENT  CORPORATION 


LSI-11 

WITH  3 

TTY/NODE  (Cont) 

LIST 

SYSTEM 

DISCOUNT 

QTY 

ITEM 

PRICE 

PART  MO. 

USAGE (*) 

(%) 

cot 

Link 

■ Termination  Group: 

2 

LSI-11  & 4 Kw  RAM 

1696 

11/03-DA 

10 

15 

2883 

5 

4Kw  RAM 

469 

MSV11-B 

30 

32 

1595 

2 

Expander  Box 

808 

BAll-MF 

10 

32 

1099 

2 

Jumper  Cable 

234 

BCVlB-04 

10 

32 

318 

11 

IOC 

129 

DRVII 

54 

32 

965 

11 

DRVII  Cable 

32 

BC042-10 

54 

32 

239 

1 

REVII-C 

300 

REVII-C 

4 

32 

204 

2 

TEVII 

85 

TEVII 

10 

32 

116 

2 

4Kb  Data  Memory 

450 

- 

- 

0 

900 

7 

Boards  & Hardware 

270 

- 

- 

0 

1890 

1 

Card  Nest 

350 

- 

- 

0 

350 

2 

4K  PROM  Card 

149 

MRVII-AA 

10 

32 

203 

64 

512x4  PROM  Chips 

22 

MRVII-AC 

320 

32 

957 

Link  Termination 

Group 

Total  Cost 

$11719 

Nodal  Processor  Group 

* 

• 

1 

LSI-11  & 4Kw  RAM 

1696 

11/03-EA 

10 

15 

1442 

6 

4Kw  RAM 

469 

MS VI I -B 

30 

32 

1914 

3 

IOC 

129 

DRVII 

54 

32 

263 

3 

DRVII  Cable 

32 

BC04&-10 

54 

32 

65 

] 

DLVII  (SLI) 

235 

DLVII 

4 

32 

160 

2 

DLVII  Cable 

40 

BC05M-1F 

8 

32 

54 

1 

TEVII 

85 

TEVII 

10 

32 

58 

1 

Expander  Box 

8G8 

BAll-ME 

10 

32 

549 

1 

Jumper  Cable 

234 

BCVlB-04 

10 

32 

159 

2 

Boards  & Hardware 

270 

- 

- 

0 

540 

1 

TTY 

1300 

- 

6 

0 

1300 

1 

4K  PROM  Card 

149 

MRVII-AA 

10 

32 

101 

32 

512x4  PROM ’Chips 

22 

MRVII-AC 

320 

32 

479 

Nodal  Processor  Group  Total  Cost 


$7084. 


*Item  cost  and  system  image  is  based  on  quantities  needed  for  a 2-node 
network . 
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TABLE  II-l.  DETAILED  COST  ESTIMATES:  DIGITAL  ECU I PM ENT  CORPORATION 

LSI -I I WITH  3 TTY /NODE  (Cent) 

LIST  SYSTEM  DISCOUNT 


CTY 

DEC 

ITEM 

Off-Line  Software 

PRICE  PAPT  NO.  USAGE (*) 

Develooment  System: 

m 

COST 

1 

System  Basics 

8883 

11V03-EA 

1 

15 

7551 

3 

SLI 

235 

DLVI I 

7 

32 

479 

3 

DLVII  Cable 

34 

BC05M-1F 

11 

32 

69 

4 

4Kw  RAM 

469 

MSVII-B 

34 

32 

1276 

1 

DFCpr inter 

3585 

LA180-CA 

1 

32 

2438 

1 

DECwr iter 

2350 

LA36-DE 

1 

32 

1598 

1 

BASIC/RT-11 

500 

QJ921-AY 

1 

32 

340 

DEC  Off-Line  Software  Development  System  Total  Cost  $13751. 


*Fased  on  a 2-node  network. 
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TABLE  I 1-2.  DETAILED  COST  ESTIMATES:  DATA  GENERAL 

CORPORATION,  P NOVA  WITH  3 TTY/NODE 


LIST 

SYSTEM 

DISCOUNT 

OTY  ITEM 

PRICE 

PART  NO.  USAGE (*) 

(%)  COST (*) 

Access  Ccuipmen t Group : 


2 

TTY 

1300 

- 

- 

0 

2600 

1 

pNOVA  & 4 Kw  RAM 

1995 

8561 

10 

26 

1476 

(9  slot) 

1 

PNOVA  & 4 Kw  RAM 

2595 

8560 

10 

26 

1920 

*18  slot) 

9 

8 Kw  RAM 

950 

8573 

26 

29 

1349 

13 

IOC  Bd. 

250 

4210 

54 

36 

2080 

13 

10  Cables 

21 

- 

.. 

0 

273 

(3'-48  cond.) 

2 

SLI 

250 

4207 

8 

23 

385 

2 

SLI  Cables 

5 

- 

8 

0 

10 

(6  * — 6 cond.) 

2 

4Kb  Data  Memory 

450 

- 

- 

0 

900 

12 

Boards  6 Hardware 

270 

- 

— 

0 

3240 

1 

Card  Nest 

350 

- 

- 

0 

350 

2 

4Kw  PROM 

750 

- 

26 

29 

1065 

Access  Equipment 

Group 

Total  Cost: 

$15,648, 

Node  Power  Supply  6 Cabinet 

• 

• 

1 

Power  Supply 

200 

— 

- 

0 

200 

1 

Cabinet  Rack** 

550 

— 

0 

550 

Node  Power  Supply 

and  Cabinet  Total 

Cost 

$750 

Link  Termination  Group: 

2 

P ’ 'OVA  & 4 Kw  RAM 

1995 

8561 

10 

26 

2953 

(9  slot) 

2 

8 Kw  RAM 

950 

8573 

26 

29 

1349 

1 

4 Kw  RAM 

600 

8572 

26 

29 

426 

11 

XOC  Bd. 

250 

4210 

54 

36 

1760 

11 

10  Cables 

21 

- 

- 

0 

231 

2 

4Kb  Data  Memory 

‘450 

- 

— 

0 

900 

7 

Boards  & Hardware 

270 

- 

- 

0 

1890 

1 

Card  Nest 

350 

- 

- 

0 

350 

2 

4Kw  PROM 

750 

— 

26 

29 

1065 

Link  Termination 

Group 

Total  Cost 

$10,924 

* Based  on  2-Node  Network. 

**  2 needed  per  node  when  servicinq  2 or  more  links. 
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TABLE  II-2.  DETAILED  COST  ESTIMATES:  DATA  GENERAL 

CORPORATION,  pNOVA  WITH  3 TTY/NODE  (Cont) 


LIST  SYSTEM  DISCOUNT 


OTY 

ITEM 

PRICE 

PAPT  NO. 

USAGE (*) 

(%) 

COST (*) 

Nodal  Processor  Group: 

1 

pNOVA  & 4 Kw  RAM 

1995 

8561 

10 

26 

1476 

(9  slot) 

3 

8 Kw  RAM 

950 

8573 

26 

29 

2024 

3 

IOC  Bd. 

250 

4210 

54 

36 

480 

3 

10  Cables 

21 

- 

- 

0 

63 

2 

SLI 

250 

4207 

3 

23 

385 

2 

SLI  Cables 

5 

- 

8 

0 

10 

2 

Boards  6 Hardware 

27C 

- 

- 

0 

540 

1 

TTY 

1300 

- 

- 

0 

1300 

1 

4 Kw  PROM 

750 

- 

26 

29 

533 

Nodal  Processor  Group  Total 

Cost 

$6,811. 

* Based  on  a 2-node  network. 


Data  General  Off-Line  Software 
Development  System; 

A Data  General  Sales  Engineer  has  indicated  that  an  off-line 
software  development  system,  having  a capability  similar  to  the  DEC 
development  system  for  $13,731.00  would  cost  approximately  $20,000  to 
$25,000.  An  average  of  $22,500  has  been  used  here. 
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